How to read a CSR: SANs, common name, and what actually ends up in the 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.
Tip
Inspect the current certificate, key, token, or endpoint output before changing deployment config; stale artifacts make fixes misleading.
A CSR is not a certificate. It is a signed request that says, in effect, “please issue a certificate with these names and this public key.” That difference matters because people often read too much into the request and too little into the issued result.
The useful move is to make CSRs inspectable instead of mystical.
Summary
Definition: 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.
Pitfall: The common name is not the whole story. Modern clients care about SANs, and the CA may not honor every field the way you assume.
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.
For small-site owners, the key insight is simple: write down the full set of names that must work before you generate the request. That keeps the request from becoming a guess.
- Use SANs for the hostnames you truly need.
- Do not expect wildcard coverage to solve unrelated names.
- 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.
Quick example
Use this when you want a short OpenSSL command to inspect a CSR before submission.
What to 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
Practical check
- 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.
FAQ
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?
No. The CSR contains the public key and a signature generated by the private key.
Developer workflow
Use this guide as an operations checklist before changing certificates, tokens, DNS, or deployment settings.
- Inspect the current artifact or endpoint output before making changes.
- Change one variable at a time so a failed verification has a narrow cause.
- Keep the rollback value, expiry, and verification command in the same runbook entry.
1. current deployed artifact
2. single config or key change
3. verify endpoint/client behavior
4. record rollback and expiry details