How to Decode a CSR Before Sending It to a Certificate Authority

You've generated a Certificate Signing Request for a new TLS certificate, and now you're staring at a wall of base64 text about to paste it into a Certificate Authority's order form. Before you click submit, it's worth spending sixty seconds decoding it — a CSR with the wrong domain name, the wrong key size, or a mismatched country code is one of the most common reasons cert issuances get delayed or rejected. Worse, a CSR generated against a weak key or the wrong algorithm can produce a certificate that looks valid but isn't actually trustworthy.

The CSR Decoder runs entirely in your browser, so you can paste a real production CSR and inspect it without uploading anything.

What a CSR actually is

A Certificate Signing Request is a small, signed file in PKCS#10 format. It contains three things and three things only:

• A Distinguished Name (DN) — the Subject of the certificate: country, organization, organizational unit, common name, etc.
• A public key — the key the CA will associate with your certificate.
• A signature — proof that you actually hold the corresponding private key (the CA never sees the private key itself).

When a CA signs your CSR, it takes that public key and Subject, puts them into an X.509 certificate, signs the certificate with its own key, and gives it back to you. Anything wrong in the CSR will end up baked into the certificate — and reissuing costs time.

Before and after: a typical CSR decoded

Here is the raw CSR a developer might paste into a CA's order page:

-----BEGIN CERTIFICATE REQUEST-----
MIIDIjCCAggCAQAwgYkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApTb21lLVN0YXRl
MRIwEAYDVQQKDAlFeGFtcGxlSW5jMRcwFQYDVQQDDA5hcGkuZXhhbXBsZS5jb20x
...
-----END CERTIFICATE REQUEST-----

Decoded, that same CSR tells you exactly what you're about to ask for:

Field	Value
Version	PKCS#10 v1
Subject CN	api.example.com
Subject O	ExampleInc
Subject C	US
Subject L	California
SAN DNS	api.example.com, www.example.com
Public Key	RSA 2048-bit
Signature Algorithm	SHA-256 with RSA
Signature	Verified against embedded public key

Every one of those values is something you can — and should — verify before submitting.

Step 1: Check the Subject

The Subject is the identity baked into the certificate. For a domain-validated TLS cert, the most important field is CN (Common Name) — but here's a critical point that catches many people: modern browsers ignore CN and require the Subject Alternative Name (SAN) for hostname matching. CN still has to be present for legacy compatibility, but it won't be what the browser checks.

What you should look at in the Subject:

• CN matches the primary hostname you expect.
• O (Organization) and OU (Organizational Unit) are correct for OV/EV certificates — wrong values here are a frequent typo.
• C (Country), ST (State), L (Locality) match your company's registered address; a single character off can cause CA validation to fail.

Step 2: Verify the SAN list

Open the Subject Alternative Name extension. This is the actual list the browser will use. Common mistakes:

• Forgetting the www variant (or vice versa — including www when you only serve apex).
• Missing subdomains the application actually serves (api., cdn., m., regional variants).
• Adding wildcards you don't actually need (a wildcard *.example.com covers one level, not multiple).

If a hostname your app serves isn't in the SAN list, browsers will reject the certificate with NET::ERR_CERT_COMMON_NAME_INVALID — even if CN looks right.

Step 3: Inspect the public key

The decoder shows the algorithm and size. A few rules of thumb:

• RSA 2048-bit is the modern minimum. 1024-bit is no longer accepted by major CAs and shouldn't be trusted.
• RSA 4096-bit is fine but offers little practical security benefit over 2048 and slows the TLS handshake.
• ECDSA (P-256) is a great choice — smaller, faster, equally strong. P-384 is also fine.
• Weak algorithms like DSA, or RSA keys under 2048 bits, should be regenerated.

If the public key is too weak, regenerate the CSR before submitting, otherwise you'll get a certificate you can't actually deploy.

Step 4: Confirm the signature verifies

The decoder recomputes the CSR's signature against the embedded public key. If the signature says verified, you know:

• The CSR hasn't been tampered with after generation.
• Whoever generated it held the private key.

If the signature says not verified, the CSR is corrupt or was edited after generation. Don't submit it — regenerate it.

The CN-vs-SAN pitfall

The single most common CSR mistake is treating CN as the authoritative hostname. A CSR with:

Subject CN = example.com
SAN DNS   = www.example.com

…will produce a certificate that only matches www.example.com. Browsers will refuse the bare apex. Always list every hostname you actually serve in the SAN, and treat CN as a legacy fallback rather than the source of truth.

Everything stays in your browser

The CSR Decoder runs 100% client-side. Paste a real production CSR — it's base64-encoded but it still reveals your infrastructure — and inspect it without uploading it anywhere.

Next: check the issued certificate

Decoding the CSR tells you what you're about to ask for. Once the CA returns the signed certificate, run it through the SSL Certificate Checker to confirm the chain is valid, the SAN list survived issuance, the expiry is what you expected, and the issuer is one your clients actually trust.