SSL Tools

CSR Decoder

Decode and inspect Certificate Signing Requests — view subject, key info, and SANs

Decoded entirely in your browser — nothing is sent to any server

CSR (PEM Format)

What Is a CSR and Why Decode It?

A Certificate Signing Request (CSR) is a block of encoded text submitted to a Certificate Authority (CA) when applying for an SSL/TLS certificate. It contains your public key plus identifying information — the domain name, organization, and location — signed with your private key to prove possession. Before submitting a CSR to a CA, decoding it lets you verify that every field is correct: the right Common Name, the expected key size, and any Subject Alternative Names (SANs) for multi-domain coverage.

What Fields Does a CSR Contain?

A standard PKCS#10 CSR includes a subject distinguished name (CN, O, OU, C, ST, L), a public key with its algorithm and key size (typically RSA 2048 or 4096 bits), a signature algorithm (usually SHA-256 with RSA), and optional extensions like Subject Alternative Names. The CA uses these fields to populate your final certificate. Verifying the CSR signature confirms the request was not tampered with in transit and that you hold the matching private key.

When Should You Verify a CSR?

Always inspect a CSR before submitting it to a CA. Common mistakes include misspelled domain names, missing SANs for www or API subdomains, incorrect organization details, and weak key sizes. Catching these errors before submission saves time and avoids costly re-issuance. This decoder runs entirely in your browser using the node-forge library, so your private data never leaves your device.

Expert guide · CSR Decoder

Technical background

A certificate signing request is defined by PKCS#10, republished as RFC 2986. Structurally it is an ASN.1 SEQUENCE containing a CertificationRequestInfo block (version, subject name, SubjectPublicKeyInfo and a set of attributes), followed by a signature algorithm identifier and the signature itself. The signature is computed with the private key over the CertificationRequestInfo, which is why a CSR proves possession of the key without ever containing it. When you see -----BEGIN CERTIFICATE REQUEST----- you are looking at the DER bytes wrapped in Base64 according to the textual encoding rules of RFC 7468.

Extensions that the applicant wants in the final certificate travel inside a PKCS#9 extensionRequest attribute (OID 1.2.840.113549.1.9.14). The most important one is subjectAltName. Since Chrome 58 (2017) browsers ignore the Common Name for hostname matching and look only at SAN dNSName and iPAddress entries, as required by RFC 6125 and the CA/Browser Forum Baseline Requirements, which also mandate that every publicly trusted TLS certificate carry the SAN extension. Many CAs copy the CN into the SAN list for single-name orders, but you should never rely on it for multi-domain requests.

The Baseline Requirements also govern key quality. For RSA the modulus must be at least 2048 bits and divisible by 8; for ECDSA only the NIST curves P-256, P-384 and P-521 are allowed. RSA 2048 offers roughly 112-bit security (NIST SP 800-57), RSA 3072 roughly 128-bit, and ECDSA P-256 delivers 128-bit security with a far smaller key and faster handshakes. Public CAs reject keys known to be compromised (for example Debian weak keys or keys already reported for revocation), so reusing an old key pair can cause an otherwise valid CSR to fail.

A CSR is a one-time artifact, and certificate lifetimes are shrinking. CA/B Forum ballot SC-081 approved a schedule that cuts the maximum TLS certificate validity to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. In practice that pushes everyone toward automated ACME issuance, where the client builds and submits a fresh CSR on each renewal. Post-quantum signatures such as ML-DSA (FIPS 204) will eventually appear in SubjectPublicKeyInfo as well, but they are not yet accepted for publicly trusted TLS certificates.

Common errors and how to fix them

Problem The decoder says the input is invalid even though the file came from the CA portal.: Fix Make sure you pasted the whole block including -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST-----. Windows certreq sometimes emits BEGIN NEW CERTIFICATE REQUEST, which is also accepted; a binary .der file must be converted with openssl req -inform der -in request.der -out request.csr.
Problem An ECDSA CSR fails to decode.: Fix This browser decoder only parses RSA keys. Inspect EC requests with openssl req -in request.csr -noout -text, which shows the curve (prime256v1 = P-256, secp384r1 = P-384).
Problem Subject Alternative Names list is empty.: Fix The generator did not add an extensionRequest. Regenerate with openssl req ... -addext 'subjectAltName=DNS:example.com,DNS:www.example.com' or enter the extra names in the CA order form if it supports that.
Problem Signature verified shows No.: Fix The PEM was modified after signing (line wrapping changed inside the Base64, a character lost while copying from email). Copy the original file again; never edit a CSR by hand, regenerate it instead.
Problem The CA rejects the request as a weak or blocklisted key.: Fix Generate a brand-new key pair of at least RSA 2048 or ECDSA P-256. Keys reused from a revoked or compromised certificate are refused by public CAs.

Do it from the command line

macOS

# Print every field and verify the self-signature
openssl req -in request.csr -noout -text -verify
# Show only the requested SANs
openssl req -in request.csr -noout -text | grep -A1 'Subject Alternative Name'

Windows

# Decode a CSR with the built-in certutil
certutil -dump request.csr
# Same with OpenSSL (bundled with Git for Windows)
openssl req -in request.csr -noout -subject -verify

Linux

# Full decode plus signature check
openssl req -in request.csr -noout -text -verify
# Fingerprint the public key to compare with the key file later
openssl req -in request.csr -noout -pubkey | openssl sha256

Frequently asked questions

Is it safe to paste my CSR into an online decoder?

A CSR contains only public information: the public key, the domain names and organization details. It never includes the private key. On this page the decoding runs in your browser with node-forge and the text is not sent to any server, so even internal hostnames listed in the request stay on your machine.

Does the Common Name still matter in a CSR?

Not for browsers. Since 2017 Chrome, Firefox and Safari match the hostname only against Subject Alternative Names, and the CA/B Forum Baseline Requirements make the SAN extension mandatory. CAs still accept a CN and often copy it into the SAN list, but every name you need must end up in the SANs.

Can I reuse the same CSR to renew my certificate?

Technically many CAs allow it, but it means keeping the same private key for years. With validity periods falling to 200 days in 2026 and 47 days by 2029, the better practice is to generate a new key and CSR at each renewal, ideally automatically through an ACME client.

What key size should my CSR use?

RSA 2048 is the accepted minimum and remains fine for certificates with short lifetimes. RSA 3072 gives roughly 128-bit security, and ECDSA P-256 gives the same strength with smaller keys and faster handshakes. RSA 4096 is valid but adds CPU cost on every TLS handshake without a meaningful practical gain.

Why does my CSR show sha256WithRSAEncryption if I asked for SHA-384?

The signature algorithm in the CSR only protects the request itself. The CA chooses the hash used to sign the issued certificate, usually SHA-256 for RSA issuers or SHA-384 for P-384 issuers. A SHA-256 signed CSR is perfectly acceptable everywhere.