SSL guides & resources
CSR and private keys: what to create, share and protect
Understand the difference between a CSR, certificate and private key. Prepare certificate requests and agree a secure installation and handover process.
Many installation delays begin when the buyer, developer and hosting administrator each assume someone else retained the private key. Decide who creates the key, where it is stored and who installs the issued certificate before submitting the request.
This guide concerns ordinary website TLS requests. Code signing, managed cloud services and hardware-backed systems can require different key generation and storage workflows. Follow the platform and issuer requirements for that certificate type.
In this guide
A practical checklist
Choose the key’s owner and storage location
Prefer the intended server or the platform’s approved key-management mechanism. Use restricted access and a documented backup policy. A supplier normally needs your CSR to process a request, not unrestricted access to the private key.
Prepare the exact certificate names
List the fully qualified domain names and required SANs. Confirm wildcard requirements with the product selected. Do not assume a display name, URL path or organization name can substitute for the hostname.
Generate and inspect the CSR
Use the hosting interface or supported tools such as OpenSSL according to current issuer requirements. Check the request’s names and public-key details before submission. CSR information is not itself proof that the requester controls the domain.
Complete validation and receive the certificate
Submit the CSR through the order workflow and complete the issuer’s checks. Retain the issued certificate and intermediate chain separately from the private key. Keep the order reference so future reissuance can be traced.
Verify the match and complete handover
Have the administrator verify that the issued certificate matches the private key before deployment. Record the key’s protected location, certificate expiry, server owner and replacement procedure. Avoid duplicating keys onto unnecessary machines.
Common problems and decisions
The private key is lost
The certificate authority cannot reconstruct it from the CSR or certificate. Generate a new key and request reissuance through the proper process; confirm whether any existing deployment must be replaced.
A key was exposed
Treat this as an incident. Restrict access, notify the responsible security administrator and arrange replacement/revocation with the issuer as appropriate. Removing a public file does not prove that nobody copied it.
An installer asks for a PFX file
A PKCS#12/PFX package may contain the private key as well as certificates. Treat it as sensitive, agree a protected transfer mechanism and handle its password separately. Do not attach it to an ordinary support thread.
Prepare for the next conversation
A practical handover record should identify the domain list, CSR creator, key custodian, hosting environment, issuer/order reference and renewal owner. For an agency-managed Bangladesh website, make sure the business retains an authorized recovery route if the developer changes. Record access responsibilities without copying passwords into the handover document.
Continue with the right guide or service
Common questions
Is a CSR the same as a certificate?
No. A CSR is a request containing a public key and proposed information. An issued certificate is signed by the certificate authority after the relevant checks.
Can the certificate authority give me my private key?
Not when you generated and retained it yourself. The normal CSR process does not transmit that key to the authority.
Is it safe to share a certificate file?
A public certificate is designed to be presented to clients. Check the file contents first: a combined PEM or PFX may also include private key material.
Can I reuse the same key forever?
Do not assume that is an acceptable policy. Follow platform, issuer and organizational key-management requirements, and replace exposed or unsuitable keys.