BYTETOOLS

CSR Decoder

Decode a PKCS#10 certificate signing request to verify the subject, key size and requested SANs before you send it to a certificate authority.

…or drop a .csr / .pem fileRead locally — never uploaded

What is the CSR Decoder?

A CSR decoder parses a certificate signing request and shows the distinguished name, public key algorithm and size, requested Subject Alternative Names and signature algorithm — so you can check it is correct before paying a CA to sign it.

  • Field-by-field subject breakdown: CN, O, OU, L, ST, C and emailAddress
  • Public key algorithm, key size, curve and exponent
  • Requested subjectAltName entries pulled from the extensionRequest attribute
  • Checklist covering missing SANs, weak keys, SHA-1 signatures and wildcard CNs
  • Counts of blocking issues and warnings at a glance
  • Runs offline in your browser — the request is never transmitted

How to use the CSR Decoder

  1. 1

    Paste the CSR including the BEGIN CERTIFICATE REQUEST line, or drop a .csr or .pem file.

  2. 2

    Click Decode CSR, or use Load sample CSR to see how the report is laid out.

  3. 3

    Read the Subject Distinguished Name panel and confirm every field is spelled the way your CA expects.

  4. 4

    Check the requested Subject Alternative Names — this is the list the issued certificate will actually cover.

  5. 5

    Work through the CA acceptance checklist and fix anything marked as a blocking issue before you order.

About the CSR Decoder

A certificate signing request bakes in your organisation details, your hostnames and your key. Get one field wrong and the CA either rejects the order or issues a certificate you cannot use. This decoder opens the PKCS#10 structure and shows every field it contains, one line at a time.

Alongside the raw fields it runs a checklist of the mistakes certificate authorities reject most often: a missing subjectAltName, an RSA key below 2048 bits, a SHA-1 signature, a wildcard in the Common Name, an unusual public exponent, or a country code that is not a two-letter ISO value. Each item is marked as a pass, a warning or a blocking issue.

Parsing happens entirely in your browser using JavaScript — the request is never uploaded. A CSR contains no private key material, only your public key and the details you typed, but it is still yours, and it stays on your machine.

Frequently asked questions

How do I check a CSR before sending it to a CA?

Paste it above and click Decode CSR. Confirm the Common Name and organisation are spelled correctly, that every hostname you need appears in the SAN list, and that the key is at least 2048-bit RSA or an elliptic-curve key. Fixing it now is much faster than reissuing later.

Why does my CSR need a subjectAltName if it already has a Common Name?

Browsers stopped using the Common Name for hostname verification years ago. If the SAN list is empty, the certificate you get back will fail in Chrome, Firefox and Safari no matter what the CN says. Most CAs copy the CN into the SAN list, but you should not rely on it.

Can I edit a CSR after generating it?

No. The request is signed with your private key, so changing any field invalidates the signature. Generate a fresh CSR with the corrected details — you can reuse the same private key if you want to, using openssl req -new -key existing.key.

Does a CSR contain my private key?

No. It contains your public key plus the subject details, all signed by the private key to prove you hold it. That signature is why a CSR is safe to email to a certificate authority, and why this tool can read one without ever seeing your private key.

What key size should I use for a new CSR?

2048-bit RSA is the accepted minimum and the most compatible choice. ECDSA on P-256 is smaller and faster and is accepted by every major CA. Anything below 2048-bit RSA is refused outright under the CA/Browser Forum Baseline Requirements.

Related tools