What a CSR contains
- Public key — the key that ends up in the certificate.
- Subject — the domain (Common Name) and optionally organisation, country, etc.
- SAN fields — additional domains the certificate should cover.
- Signature — the CSR is self-signed with the corresponding private key, proving you own the key pair.
The private key never leaves your server — it is not part of the CSR. That is the whole point: the CA only sees the public key.
How the flow works
Classic flow: you generate a key pair + a CSR, send the CSR to the CA, the CA validates and returns a signed certificate, and you install it alongside the private key. How thoroughly the CA validates depends on the DV/OV/EV level.
Why you rarely see a CSR anymore
With ACME automation (Let's Encrypt, ZeroSSL and others) the key and CSR are generated automatically by the client at every renewal. You never touch it by hand. The CSR still exists under the hood — it has just become invisible, which is a good thing.
The private key is what matters
A certificate is public; security depends entirely on keeping the private key secret. If it leaks, others can impersonate your domain — which is why short lifetimes and staying on top of renewals matter so much.
How CertControl helps
CertControl keeps track of certificates after issuance: where they are installed, which key/issuer they use, and when they need renewing — whether they came from a manual CSR or from ACME.
Frequently asked questions
Does a CSR contain my private key?
No. A CSR contains only the public key and domain information. The private key stays on your server and must never be shared.
Do I need to create a CSR manually?
Not if you use ACME. Clients for Let's Encrypt, ZeroSSL and others generate the key and CSR automatically at every renewal.
What is the Common Name in a CSR?
The primary domain the certificate is issued for. Additional domains are listed in the SAN fields.