CSR Decoder

Paste a Certificate Signing Request below and this CSR decoder will show you what is actually inside it: the Common Name and the rest of the Distinguished Name, the public key and its key size, the signature algorithm, and every Subject Alternative Name the request covers.

Reading those fields takes a few seconds. Skipping them costs a reissue. A Certificate Authority will happily sign a CSR with a mistyped domain in it, and you find out when browsers start throwing name mismatch errors on a certificate you have already paid for and installed.

Decode Your CSR File

Paste the full text of your CSR into the box, including the header and footer lines:

A valid CSR opens with —–BEGIN CERTIFICATE REQUEST—– and closes with —–END CERTIFICATE REQUEST—–.

Windows servers running IIS write the opening line as —–BEGIN NEW CERTIFICATE REQUEST—–. Both forms work here. The file may arrive with a .csr, .pem or .txt extension; only the text inside it matters. This free online CSR decoder reads PEM, the Base64 format that almost every server and hosting panel produces.

Do not have a CSR yet? Generate one with our CSR generator, or follow the CSR guide for your platform.

What the CSR decoder shows you

Every CSR carries two things a Certificate Authority needs: who you say you are, and the public key you want certified. The identity half is called the Subject, or Distinguished Name, and it is a set of labelled fields rather than one long string. The decoder splits the Distinguished Name into its parts and reports the key details alongside it.

The table below covers every field this CSR decoder returns, what a valid value looks like, and what goes wrong when it is not.

A CSR can also hold optional attributes and requested extensions that most decoders skip over. A challenge password is an optional string some CAs once used to authorise revocation; leave it empty unless your CA asks for one. Requested extensions such as keyUsage, extendedKeyUsage and basicConstraints describe what the certificate should be allowed to do, though the CA sets the final values.

How CSR decoding works

A CSR is a PKCS#10 certification request, a format defined by RFC 2986. Its contents are described in ASN.1, serialised into DER, which is binary, then Base64-encoded and wrapped in the PEM header and footer lines so the request survives email and copy-paste without corrupting.

Decoding reverses that chain. The tool strips the PEM wrapper, turns the Base64 back into DER, parses the ASN.1 structure, and labels every value it finds.

No decryption happens at any stage, because nothing in a CSR is encrypted. A CSR holds your public key. The private key stays on the server that generated it and never goes into the request at all. Anyone who intercepts a CSR can read it, which is precisely why it is safe to email one to a Certificate Authority.

What a CSR does carry is a signature. The request is signed with the private key matching the public key inside it, which proves you hold that key. This is called Proof of Possession, and it is how a CA knows the person asking for a certificate controls the key being certified.

Once the CA validates the request, it issues an X.509 certificate containing your public key and whichever Subject fields it was able to verify.

What to check before you submit your CSR

Run the decoded output past this list before the request goes anywhere near a Certificate Authority. Using the decoder as a CSR checker at this point costs you a minute. Catching the same mistake after issuance costs a reissue and a redeploy.

1. The Common Name matches your fully qualified domain name exactly, including or excluding www as you intended. example.com and www.example.com are two different names.
2. Every domain you need appears in the SAN list, not only in the Common Name.
3. The country is exactly two letters. Check it against the ISO 3166-1 alpha-2 list if you are unsure.
4. State and locality are spelled out, not abbreviated.
5. The organization is your registered legal name, if you are buying an OV or EV certificate. Domain Validated certificates ignore this field.
6. The key is 2048-bit RSA or larger, or 256-bit ECDSA or larger.
7. The signature algorithm is SHA-256 or stronger.
8. Wildcard syntax is *.example.com, which covers one level only. It does not cover shop.eu.example.com.
9. You still hold the private key this CSR was generated from. Confirm it with the Certificate Key Matcher before you order.

Common CSR problems a decoder reveals

Name mismatch. The Common Name or the SAN list does not match the domain the server actually answers on. This is the single most common reason a certificate installs and still fails in the browser.

Missing SAN. The certificate was issued, the Common Name looks right, and one hostname still errors. Decode the CSR and check whether that hostname was ever in the SAN list. If it was not, it was never covered.

A rejected country code. Three letters instead of two. The CA rejects the request, usually with a message that does not name the field.

An abbreviated state. CA instead of California, NY instead of New York. Domain Validated orders pass. Organization Validated and Extended Validation orders stall in validation until you resubmit.

A key that is too small. 1024-bit RSA has been unacceptable to public CAs for years. Regenerate the CSR with a 2048-bit key or larger; you cannot fix this by editing the request.

The OU field vanished. You put a department in the Organizational Unit field and it is not in the issued certificate. That is expected behaviour since September 2022, not a mistake on the CA’s side. Read why the OU field was removed.

A CSR that does not match your private key. Usually the result of generating a second CSR and losing track of which key pair went with which request. The Certificate Key Matcher settles it in one step.

An international domain in the wrong form. Non-ASCII domains have to appear in Punycode, the xn-- form, rather than in their native script.

Decode a CSR with OpenSSL

If you have OpenSSL installed, you can read a CSR without a browser:

openssl req -in example.csr -noout -text

Add -verify to check the request’s own signature at the same time, which confirms the CSR has not been altered since it was generated:

openssl req -in example.csr -noout -text -verify

The output puts the whole Distinguished Name on the Subject: line, in one comma-separated run rather than as separate fields, so read it left to right: C, ST, L, O, OU, CN. Below that, Public Key Algorithm names RSA or ECDSA, and Public-Key: gives the bit length in brackets. Signature Algorithm appears twice, once near the top and once at the bottom next to the signature block; both refer to the CSR’s own signature.

Subject Alternative Names are easy to miss. They are not part of the Subject line. Look further down for the Requested Extensions block and the X509v3 Subject Alternative Name entry underneath it. If that block is absent, the CSR has no SANs at all.

The web tool above is the faster option when OpenSSL is not installed, when you are on Windows without WSL, or when the CSR came out of a hosting panel and only exists as text in a browser tab. The output is the same information, labelled in plain language.

Decoding a CSR for Sectigo, DigiCert or any other CA

A CSR is a PKCS#10 file, and the format does not change based on who will sign it. There is no Sectigo-specific or DigiCert-specific CSR format, so one decoder works for requests destined for any Certificate Authority.

What does vary between CAs is which fields get validated and how strictly. Domain Validated certificates only check control of the domain and ignore the Organization field entirely. Organization Validated and Extended Validation certificates require the Organization, Locality, State and Country fields to match public records, which is why the accuracy of those fields matters more the higher up the validation ladder you go.

Frequently Asked Questions