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.
The useful move is to make CSRs inspectable instead of mystical.
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 CSR proves that whoever generated it had the private key needed to sign the request. It also carries the public key and requested subject information. That is useful, but it is narrower than many people think. A CSR does not guarantee that the CA will issue exactly those attributes, and it does not itself establish public trust.
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.