Certificates & Site Ops
How to Read a CSR and Compare the Issued Certificate
A practical CSR guide that explains what you are really requesting, what CAs use, and why SANs matter more than the old common-name habit.
A CSR is a signed request for a certificate with specified names and a public key. Inspect the issued certificate separately because it may differ from the request.
Decode the CSR to check its public key, requested names and signature.
In brief
What it is: A CSR is a PKCS #10 object containing a subject, public key, optional attributes, and a signature proving possession of the matching private key.
Why it matters: Reading the CSR before submission helps you catch name mistakes, SAN omissions, and key mismatches before the CA ever issues anything.
Worth knowing: Review the SAN extension and the CA's issued certificate together; modern clients use SANs for hostname coverage.
What a CSR actually proves
A valid CSR signature shows that the matching private key signed the request. The CSR also contains the public key and requested subject information. The CA checks the request before issuing a certificate and may change or omit requested attributes, so compare the issued certificate with the request.
This is why inspection matters. The CSR is your chance to see whether the request contains the names and key you intended before another system turns it into a certificate.
SANs are where hostname reality lives
The Subject Alternative Name extension is what modern hostname validation relies on in practice. The common name is still visible and historically familiar, but treating it as the primary hostname field causes avoidable mistakes. If the SAN list is wrong or incomplete, the certificate will still disappoint you even when the common name looks perfect.
Before generating a CSR, list every hostname that the certificate must cover.
- Use SANs for the hostnames you truly need.
- List unrelated names explicitly; wildcard coverage normally applies to one label level within its domain.
- Inspect the final certificate, not only the original CSR.
A practical inspection workflow
Read the subject. Read the SAN list. Confirm the key type and size or curve. Then compare the request to the certificate you actually received. This two-step habit closes the gap between “what I asked for” and “what was issued.” That gap is where most support tickets live.
Use the CSR Decoder & Inspector to read requested fields and verify the CSR's self-signature. If you also have the issued certificate or a key file, use the Certificate, Key & CSR Matcher to compare their canonical public keys. A key match and a SAN comparison answer different questions, so check both.
See it in a small example
Notice: You are looking for the SAN list, subject information, and public-key details. This command does not tell you what a CA will ultimately issue; it tells you what you requested.
openssl req -in request.csr -noout -text
What to verify
- Inspect the CSR before submission, not only after issuance.
- Confirm the SAN list covers every hostname you intend to serve.
- Compare the issued certificate to the original request instead of assuming they match.
Common questions
Does the common name still matter?
It still appears, but hostname validation relies primarily on SANs in modern practice.
Can a CSR contain the private key?
The CSR contains the public key and a signature generated by the private key.
