CSR Decoder

Paste a certificate signing request to see exactly what it asks for — before a certificate authority issues against it.

The CSR you paste stays in your browser. This tool makes no network request — nothing is uploaded, logged or stored.

What gets checked

Beyond decoding the fields, this flags the defects that make a CA reject a request or a browser reject the resulting certificate: no subject alternative names, a common name missing from the SAN list, an undersized RSA key, or a deprecated SHA-1 signature. A CSR is signed by the key that made it, so none of these can be patched afterwards — the fix is always to generate a new request.

# The equivalent OpenSSL command
openssl req -in request.csr -noout -text -verify

Need to create one instead?

The CSR generator builds a request and a matching private key in your browser, with the SAN list filled in correctly by default. If you already have a CSR and a key and want to know whether they go together, use the key matcher.

CSR decoder FAQ

What is a CSR decoder?

A CSR decoder reads a PKCS#10 certificate signing request and shows what it actually asks for: the common name, the organisation details, the subject alternative names, and the type and size of the key. Certificate authorities issue exactly what the CSR requests, so decoding it first is the last cheap moment to catch a typo.

Why should I decode a CSR before submitting it?

Because a CSR is submitted blind. Once a CA signs it you get back a certificate for whatever was in it — a misspelled domain, a missing www, an internal hostname you meant to remove. Some CAs charge for a reissue, most cost you an hour, and a few validation types make you redo domain control. Ten seconds of checking avoids all of that.

Is it safe to paste a CSR here?

Yes. A CSR contains only your public key and the identity details you are requesting — it holds no secret material, which is why it is safe to email to a CA in the first place. On top of that, this decoder runs entirely in your browser and makes no network request, so nothing you paste reaches us at all.

What does the tool warn me about?

Missing subject alternative names (a certificate with only a common name is rejected by every modern browser), a common name that is absent from the SAN list, RSA keys under 2048 bits that public CAs refuse to sign, and SHA-1 signatures that are long deprecated. Each is a genuine reason a CA or a browser would reject the result.

Can I tell which private key a CSR belongs to?

Yes — that is exactly what the key matcher does. It compares the public key inside the CSR with the one derived from your private key and tells you whether they are the same pair, without the key leaving your browser. This is the usual way to work out which of several key files on a server actually goes with a request.

How do I decode a CSR with OpenSSL?

Run: openssl req -in request.csr -noout -text -verify. The -verify flag additionally checks the CSR’s self-signature, confirming the request was genuinely signed by the key it names.

My CSR has no SANs. Does that matter?

Yes, and it is the single most common defect. Chrome, Firefox and Safari all stopped honouring the common name for hostname matching years ago and look only at the SAN list, so a certificate issued from a SAN-less CSR will fail in every browser regardless of how correct the common name is. Regenerate the CSR with a SAN entry for every hostname you serve.

More free SSL tools

Stop checking by hand

Once the certificate is issued and deployed, SSLNudge watches it and warns you before it expires.

Start monitoring free