A Request, Not a Certificate
The most important thing to grasp first is that a CSR is an application, not the finished product. You generate it; a certificate authority turns it into a certificate. The CSR carries everything the CA needs to issue the certificate — your public key and your identifying details — bundled together and signed by you. The CA validates it, adds its own signature, and hands back the actual certificate. Same public key, same details, but now vouched for by an authority that browsers trust.
A CSR is usually a short PEM-encoded block that begins and ends with recognisable markers:
-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMx...
-----END CERTIFICATE REQUEST-----The scramble in the middle is the encoded request. It looks opaque, but it is just a structured container holding a handful of well-defined fields.
The Key Pair Behind It
Generating a CSR does two things at once. First it creates a key pair — a matched public key and private key, the foundation of asymmetric encryption. Then it builds the CSR around the public half. This split is the whole security model of the system:
- The public key goes into the CSR and, eventually, into the public certificate. It is meant to be shared with the world.
- The private key never leaves your server. It is not in the CSR, not sent to the CA, not in the certificate. It stays secret.
The CSR is signed using that private key. This is a quiet but clever proof: because only the holder of the private key could have produced a signature that the public key verifies, the signature demonstrates the applicant actually controls the key they are asking to have certified. The CA can confirm this without ever seeing the private key itself.
What's Inside a CSR
| Field | Contains |
|---|---|
| Public key | The public half of the generated key pair — the heart of the request |
| Common Name (CN) | The primary domain the certificate is for, e.g. example.com |
| Subject Alternative Names | Any additional domains the certificate should cover (the field browsers actually check today) |
| Organization details | Company name, locality, country — included for certificates that assert organizational identity |
| Signature | The whole request signed by the private key, proving control of the key |
One detail worth knowing: although the Common Name field is the traditional home of the domain name, modern browsers ignore it and read the Subject Alternative Names instead. A certificate with a domain only in the CN and not in the SAN list will be rejected — so the SAN field is where the names that matter must appear.
From CSR to Certificate, Step by Step
- Generate the key pair and CSR on your server. The private key is written to disk and kept; the CSR is produced for sending.
- Submit the CSR to a certificate authority.
- Prove control of the domain. The CA requires you to demonstrate you actually own the name in the request — typically by placing a specific file or DNS record it can check. This is the step that stops anyone from getting a certificate for a domain they do not control.
- Issue. Satisfied, the CA signs your public key and details, producing the certificate and the chain that links it to a trusted root.
- Install the certificate on your server, where it pairs with the private key that never left. The two halves are reunited, and the server can now complete a TLS handshake.
Where the CSR Went: Automation
If you have set up HTTPS recently, you may never have seen a CSR — and that is by design. Automated certificate systems perform every step above for you: they generate the key pair and CSR, submit it, complete the domain-control check, and install the issued certificate, then renew it automatically before it expires. The CSR is still created under the hood on every request; the tooling simply spares you from handling it. You generally craft a CSR by hand only when a particular process demands it, such as certain commercial certificates or organizational validation that cannot be fully automated. Either way, the underlying exchange is unchanged: a public key and an identity, signed by their owner, sent off to be vouched for. For how that vouching fits into the wider trust system, see how TLS works.
Frequently Asked Questions
What is a CSR?
A certificate signing request — a small encoded file you generate and send to a certificate authority to apply for a TLS certificate. It contains your public key and identifying details and is signed with your private key to prove you hold it. The CA uses it to create and sign the certificate it issues back.
What information does a CSR contain?
The public key, the domain name or names (common name and subject alternative names), and organizational details for certificates that include them. It does not contain the private key, and the whole request is signed with the private key so the CA can confirm the applicant controls it.
Does a CSR contain the private key?
No. Generating a CSR creates a key pair; only the public key goes into the CSR. The private key stays on your server and must never be shared. If it is exposed, the paired certificate should be revoked and reissued.
What is the difference between a CSR and a certificate?
A CSR is an unsigned application carrying your public key and details that you send to a CA. A certificate is the issued result — the same public key and details, now signed by the CA so browsers trust it. You create the CSR; the CA turns it into a certificate.
Do I still need a CSR with automated certificates?
Yes, but the automation hides it. Automated tools generate the key pair and CSR, submit it, prove domain control, and install the certificate for you. You only create one by hand when a process requires it, such as certain commercial or organizational certificates.