CSR Decoder

CSR Decoder quickly checks the structural validity of a Certificate Signing Request (CSR) in PEM form. It verifies that the -----BEGIN CERTIFICATE REQUEST----- block is present, that the inner base64 is intact, and that it decodes into valid DER bytes. It is ideal for catching copy-paste damage — stray line breaks or spaces — before you submit the CSR to a certificate authority.

The CSR you paste is used only for format validation and SHA-256 fingerprinting on the server and is never stored. To fully read fields like the subject (CN) and SANs, the most accurate approach is to runopenssl req -in csr.pem -noout -text locally. This tool focuses on a lightweight "is the format correct" check right before submission. Once the certificate is issued, expand it with the SSL Certificate Decoder, and after installing it on a server run a live check with the SSL Certificate Checker.

What is a CSR

A CSR is the request data you submit to a certificate authority to obtain an SSL/TLS certificate. It contains your public key and subject information (domain, organization, etc.) and is signed with your private key, usually encoded as Base64 PEM text. The private key itself is never part of the CSR, so it is safe to share.

Create and inspect a CSR with openssl

• Generate a new key + CSR: openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr
• View CSR contents: openssl req -in domain.csr -noout -text
• Verify the CSR signature: openssl req -in domain.csr -noout -verify
• Show subject only: openssl req -in domain.csr -noout -subject

Pre-submission checklist

• You pasted the entire PEM including the BEGIN/END lines
• No stray spaces or line breaks broke the base64 body
• The key is at least 2048-bit RSA or ECDSA P-256 or stronger
• The Common Name and SANs contain exactly the domains you need

CSR subject (DN) field reference

A CSR's subject is built from several RDN components, shown as abbreviations on the Subject line ofopenssl req -text output. For publicly trusted certificates issued via domain validation (DV), only the CN and SAN really matter — the rest are ignored (outside OV/EV) or collected by the CA through its own enrollment form.

Worked example: reading the openssl output

When you open a CSR this tool marks as "valid" withopenssl req -in domain.csr -noout -text, it looks roughly like the lines below. This tool only confirms the structure (header + that a public key is present) and base64/DER integrity — it does not surface the field values shown here.

• Subject: C=US, O=Example Corp, CN=www.example.com → the certified domain is the CN, www.example.com
• Public Key Algorithm: rsaEncryption / Public-Key: (2048 bit) → RSA 2048-bit, passes policy
• Requested Extensions → X509v3 Subject Alternative Name: DNS:www.example.com, DNS:example.com → both names covered
• Signature Algorithm: sha256WithRSAEncryption → if this were SHA-1, virtually every CA would reject it

If the SAN here omits the apex domain (example.com) but visitors reach the site through it, the format is still valid yet you will get a name-mismatch error after issuance. Re-check the SAN after install with the SSL Certificate Checker.

Common pitfall

• Pasting the private key instead of the CSR: a -----BEGIN PRIVATE KEY----- or RSA PRIVATE KEY header is not a CSR — a CSR must use the CERTIFICATE REQUEST header. Never paste a private key anywhere.
• The NEW CERTIFICATE REQUEST header gotcha: some Windows/IIS tools export -----BEGIN NEW CERTIFICATE REQUEST-----. It is the same PKCS#10, but the differing header string makes strict parsers reject it. Rename the header to BEGIN CERTIFICATE REQUEST and it parses identically.
• Treating "valid" as "ready to issue": a well-formed CSR still has to pass domain control validation (DCV) for its CN/SAN before a certificate is issued. A pass here just means "not corrupted."