CSR Decoder

PKCS#10 is the standard that defines the CSR format, specified in RFC 2986. It sets out which fields a certification request contains and how they are structured, which is why the same CSR works with any Certificate Authority rather than being tied to the one you bought from.

Copy Link

Because it is no longer allowed. CA/Browser Forum ballot SC47 prohibited the Organizational Unit field in publicly trusted TLS certificates issued on or after 1 September 2022, on the grounds that a CA has no reliable way to verify a department name. You can still include OU when you generate a CSR, and the decoder will show it, but the CA strips it before issuing. Nothing has gone wrong.

Copy Link

A Subject Alternative Name is an extension that lists every hostname a certificate covers. Modern browsers read the SAN list and ignore the Common Name entirely, so a domain that appears only as the Common Name and not in the SAN list will fail. Most public CAs copy the Common Name into the SAN list automatically when they issue, but confirm this with your CA rather than relying on it. If you need several hostnames on one certificate, list all of them.

Copy Link

The Subject, also called the Distinguished Name, which holds the Common Name, Organization, Organizational Unit, Locality, State and Country. The public key, with its algorithm (RSA or ECDSA) and its key size in bits. The signature algorithm the request was signed with. And, if the request includes them, the Subject Alternative Names listing every domain the certificate will cover.

Copy Link

No. Submit the encoded text exactly as your server generated it, header and footer lines included. The CA parses it on their end. Decoding is for your benefit, not theirs: it is how you catch a wrong domain or a two-letter country code before the CA turns your mistake into a certificate.

Copy Link

Yes. openssl req -in example.csr -noout -text prints the decoded contents to your terminal. Adding -verify also checks the CSR’s self-signature. See the OpenSSL section above for what each part of the output means.

Copy Link

No, because a CSR is not encrypted. This is one of the more persistent misconceptions about certificate requests. A CSR is Base64-encoded ASN.1 data, which anyone can decode with no key and no password. It contains your public key, never your private one. What people mean when they say “decrypt a CSR” is decode it, and that is what this tool and the openssl req command both do.

Copy Link

A CSR decoder takes the encoded data from a Certificate Signing Request and translates it into plain text, allowing you to understand what each field means and what the encoded value represents.

Copy Link

A CSR decoder is a tool that reads a Certificate Signing Request and displays its contents in plain language. It reverses the Base64 and ASN.1 encoding that makes a CSR unreadable by eye, then labels each field: Common Name, Organization, Organizational Unit, Locality, State, Country, public key algorithm, key size, signature algorithm and any Subject Alternative Names. You would use one to verify a request before submitting it, or to work out why a certificate you already have is behaving unexpectedly.

Copy Link

Paste it into a CSR decoder, sometimes listed as a CSR viewer or CSR reader, and read the labelled output. A CSR looks like a solid block of random characters because it is Base64-encoded binary data, so there is nothing useful to see by opening the file in a text editor. If you prefer the command line, openssl req -in example.csr -noout -text prints the same information.

Copy Link