CSR (Certificate Signing Request): the first step of every certificate
2 min read
What a CSR contains, how to generate one with OpenSSL, and how to inspect it before submitting. The private-key relationship and the most common mistakes.
What a CSR carries
A CSR is the formal application you hand to a certificate authority: your domain name(s), organisation details and your public key — signed with your own private key. The CA verifies the details and issues the certificate in response. The private key is not inside the CSR and is never shared with anyone.
A typical command: openssl req -new -newkey rsa:2048 -nodes -keyout site.key -out site.csr. Writing the domain into "Common Name" is not enough; if you need several names, generate the CSR with SAN extensions — modern certificates are read from the SAN list.
Inspect before you submit
A CSR with a typo or missing SANs comes back as the wrong certificate. Paste your CSR into the text-paste tab of SSLx: you will see the names, organisation fields and key type before anything is issued. The same tab also decodes certificates and full chains.
Common mistakes
Losing the private key (the issued certificate is useless without it — they are a pair), generating the CSR on one server and installing the certificate against a different key, and reusing an old CSR at renewal (it works, but you skip key rotation — fresh key + fresh CSR is the better practice).
Test your own site
SSLx performs every diagnosis in this guide in ten seconds: chain verification, hostname matching, expiry and HSTS — free, no signup.
Test with SSLxFrequently asked questions
Is it safe to share a CSR?
Yes; it contains only public information and the public key. The file that must never leave your server is the private key (.key) generated alongside it.
Can I submit the same CSR to multiple CAs?
Technically yes; a CSR is not CA-specific. But generating a fresh key and CSR at each renewal is the safer habit.