How to Check a CSR Before You Send It to a Certificate Authority

A certificate signing request (CSR) is a short block of text you generate on your server and paste into a certificate authority's order form. If it names the wrong domain, uses a weak key or was made with a different private key than the one on your server, you find out only after the certificate is issued, when it fails to install or browsers reject it. Checking the CSR first takes a minute.

Paste a CSR into the decoder below to see everything in it. It parses the file in your browser, so nothing is uploaded. It also reads certificates, so you can compare the issued certificate with the request afterwards.

CSR DecoderPaste a certificate signing request or an X.509 certificate to read what is inside it: subject, alternative names, key algorithm and size, validity dates, extensions and fingerprints. Everything is decoded in your browser and nothing is ever uploaded.

What is inside a CSR

A CSR is a PKCS#10 structure, usually shown in PEM form: Base64 text between -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST-----. It contains three things:

1. The subject: the name the certificate is for, such as CN=example.com, O=Example Ltd, C=GB.
2. The public key that the certificate will vouch for.
3. Requested extensions, most importantly the list of domain names in the Subject Alternative Name (SAN) extension.

The whole request is signed with the matching private key. That signature proves you hold the key without revealing it. The private key itself is never in the CSR, so a CSR is safe to share, paste into a tool or send by email.

The six checks

1. Every domain is in the SAN list

Browsers have ignored the Common Name (CN) for domain matching since Chrome 58 in 2017. Only the SAN list counts. Make sure it includes every name the certificate must cover, including both example.com and www.example.com if you serve both.

Many CAs copy the CN into the SAN list for you, but not all do, and the decoder shows exactly what you are asking for.

2. Wildcards cover what you think

*.example.com matches exactly one label: www.example.com and api.example.com, but not example.com and not v2.api.example.com. If you need the bare domain too, list it separately alongside the wildcard.

3. The key is strong enough

• RSA: 2048 bits is the minimum CAs accept. 3072 or 4096 bits is fine but slower to handshake.
• ECDSA: P-256 or P-384. These are smaller and faster than RSA at equivalent strength, and every current client supports them.

A 1024-bit RSA key will be rejected outright.

4. The signature algorithm is SHA-256 or better

The CSR's own signature should be sha256WithRSAEncryption or ecdsa-with-SHA256 (or a SHA-384 or SHA-512 variant). CAs reject requests signed with SHA-1 or MD5. Old scripts and appliances still sometimes default to SHA-1.

5. Subject fields are spelled correctly

For domain-validated certificates the CA usually ignores everything except the domain names. For organization-validated (OV) and extended-validation (EV) certificates, the subject fields are checked against business records, and a mismatch delays issuance.

• C must be a two-letter ISO 3166 code: GB, not UK; US, not USA.
• ST should be the full state or province name, not an abbreviation, for most CAs.
• O should match your legal company name exactly, including punctuation such as Ltd. or Inc.

6. It matches the private key on your server

This is the mistake that costs the most time. If you generated several CSRs, or a colleague made one on a different machine, the issued certificate will only work with the private key that made that CSR. Compare the public key in the CSR with the one derived from your private key:

openssl req -in example.csr -noout -pubkey | openssl sha256
openssl pkey -in example.key -pubout | openssl sha256

The two hashes must be identical. If they differ, the certificate will not install with that key.

Generating a good CSR with OpenSSL

With OpenSSL 1.1.1 or later, one command creates a new key and a CSR with a SAN list:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.key -out example.csr \
  -subj "/C=GB/O=Example Ltd/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

For an ECDSA key, replace -newkey rsa:2048 with -newkey ec -pkeyopt ec_paramgen_curve:P-256.

To read it back and check its signature on the command line:

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

-nodes stores the private key without a passphrase, which most web servers need to start unattended. Restrict the key file so only the server's user can read it: chmod 600 example.key.

After the certificate arrives

Paste the issued certificate into the same decoder and confirm that the SAN list, key size and subject match what you requested. Check the validity dates as well. Certificate lifetimes are shrinking under the CA/Browser Forum's schedule, so renewal is now a routine job. Automate it with ACME (Let's Encrypt or your CA's ACME endpoint) where you can, rather than repeating this process by hand.

PEM is just Base64 with header lines. If a CSR arrives mangled by an email client or a ticketing system, with extra spaces or broken lines, decoding the Base64 body directly can show whether the data underneath is intact:

Base64 Encoder & DecoderEncode text to Base64 or decode it back. Unicode is handled correctly, so Japanese, Chinese, Korean and emoji all round-trip without corruption.