CSR Decoder: Verify Your CSR Before You Issue a Certificate

The first thing you hand to a certificate authority when you request an SSL/TLS certificate is a CSR. A single typo, a wrong domain name, or a weak key size in that block can get your certificate rejected or issued with the wrong details. That is exactly where a CSR decoder earns its place: it shows you, in plain language, what your CSR actually says before you submit it.

What is a CSR?

A CSR (Certificate Signing Request) is a Base64-encoded PEM block you create to request a certificate from a CA. It contains your domain name (Common Name), your organization details, and your public key. When the CSR is generated, a matching private key is created at the same time. That private key never leaves your server and is never included in the CSR.

In short, a CSR is a signed request that says, "issue a certificate for this domain and this public key." The CA validates the request and issues a certificate bound to the public key inside it.

How is a CSR generated?

The most common tool is OpenSSL. The command below creates both a 2048-bit private key and a CSR in one go:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.key \
  -out example.csr \
  -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com"

After it runs you have two files: example.key, which you must keep secret, and example.csr, which you send to the CA. For multiple domains (SANs) you add a subjectAltName entry through a -config file.

What do the decoded fields mean?

A CSR decoder opens that PEM block and shows each field in a readable form:

  • CN (Common Name): the primary domain the certificate will be issued for, e.g. example.com.
  • O (Organization): your organization name.
  • OU (Organizational Unit): a unit or department (now optional in most certificates).
  • L / ST / C: city, state/province, and country code.
  • Key type and size: for example RSA 2048-bit or ECDSA P-256.
  • Signature algorithm: usually SHA-256 with RSA.
  • SANs: additional domain names (Subject Alternative Names) embedded in the CSR, carried in the extensionRequest.
  • Signature validity: whether the CSR's own self-signature is consistent.

Why decode your CSR before submitting it?

Decoding a CSR before submission catches hard-to-undo mistakes before they happen:

  1. Typos in the CN: a single wrong letter, like exmaple.com, gets a certificate issued for the wrong domain. The decoder shows it plainly.
  2. Missing or wrong SANs: modern browsers only look at the SAN field. If you forgot the www subdomain, the certificate won't be valid for www.example.com. The decoder lists the SANs so you can confirm them.
  3. Weak key size: an old, insecure 1024-bit key is no longer accepted. Because the decoder shows the key size, you can confirm you are using 2048-bit or higher.
  4. Wrong organization details: for OV/EV certificates the O and L fields are validated, so getting them right up front avoids days of back-and-forth.

When you're ready, use our CSR decoder tool to paste your CSR and see every field in seconds.

Runs in your browser: the privacy angle

Pasting a CSR into a random online tool can mean sending your server configuration details to a party you don't know. Our tool is different: it runs entirely in your browser. Your CSR is never uploaded to our servers; the decoding happens on your device. Even though a CSR holds no private key, this approach keeps your data with you and makes compliance with corporate privacy policies easier.

CSR looks right, what's next?

Once you've confirmed every field in your CSR is correct, you're ready to get your certificate. Follow our certificate wizard to create your free 90-day Let's Encrypt certificate step by step.

Summary

The CSR is the foundation of your certificate process, and a small mistake inside it can cause big delays. Checking the CN, organization details, SANs, and key size with a CSR decoder before you submit catches errors early. Use our browser-based tool to verify your CSR privately, then issue your certificate with confidence.