CSR Viewer

The CSR Viewer parses PEM-encoded Certificate Signing Requests and displays all the information that will appear in the resulting certificate -- subject fields, SANs, public key details, and signature algorithm -- so you can catch errors before submitting to a Certificate Authority. Paste a CSR starting with -----BEGIN CERTIFICATE REQUEST----- and instantly review every field.

Understanding Certificate Signing Requests

A Certificate Signing Request is the formal application you send to a Certificate Authority when you need a new certificate. It contains your identity information (domain name, organization details), your public key, and a list of requested extensions like Subject Alternative Names. The CSR is signed with your private key to prove you possess the corresponding key pair. The CA reviews this information, verifies your identity through domain validation or organization validation, and issues a certificate based on the CSR's contents.

The critical thing to understand is that once a certificate is issued, fixing mistakes is expensive. If you submitted a CSR with a typo in the Common Name, a missing SAN entry, or the wrong key algorithm, you will need to generate a new CSR, resubmit it, and wait for the CA to process it again. For Domain Validation certificates through Let's Encrypt, this is a minor inconvenience. For Organization Validation or Extended Validation certificates from commercial CAs, reissuance can take days and may involve additional fees. Checking the CSR before submission is always worth the thirty seconds it takes.

This viewer decodes the CSR and presents every field in human-readable format. You can verify that the Common Name matches your intended domain, that all the Subject Alternative Names are present and correctly spelled, that the key algorithm and size meet your requirements, and that the signature algorithm is current. The viewer also flags potential issues like weak key sizes, deprecated algorithms, or missing SAN entries that could cause problems during issuance.

How to View a Certificate Signing Request

1. Paste your PEM-encoded CSR (starting with -----BEGIN CERTIFICATE REQUEST-----)
2. The viewer extracts and displays all CSR fields
3. Review subject details, SANs, key information, and any validation warnings
4. Verify accuracy before submitting the CSR to your CA

Example CSR Output

Pasting a typical multi-domain CSR:

Subject:
  Common Name (CN):  www.example.com
  Organization (O):  Example Inc.
  Locality (L):      San Francisco
  State (ST):        California
  Country (C):       US

Requested SANs:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: cdn.example.com

Public Key:
  Algorithm:  RSA
  Key Size:   2048 bits

Signature:
  Algorithm:  SHA-256 with RSA

Key Validation Checks

The viewer flags potential issues automatically:

When to Use This Tool

• Pre-submission verification -- review a CSR before sending it to a Certificate Authority, especially for expensive EV (Extended Validation) or OV (Organization Validation) certificates where reissuance costs time and money
• Automated CSR auditing -- verify that CSRs generated by ACME clients, Terraform, Ansible, or other automation tools contain the correct domains and organization details
• Debugging certificate issuance failures -- when a CA rejects a CSR, inspect it to identify weak keys, missing fields, or formatting problems
• Team review -- audit CSRs created by other team members before they are submitted, ensuring naming conventions and domain coverage are correct
• Comparing CSR to issued certificate -- verify that the CA issued a certificate matching what was requested
• Key algorithm verification -- confirm whether a CSR uses RSA or ECDSA before submitting, especially when migrating key types

How Certificate Signing Requests Work

A CSR is a message sent from an applicant to a Certificate Authority to apply for a digital identity certificate. The CSR contains:

1. Subject Distinguished Name -- identifies who is requesting the certificate (CN, O, OU, L, ST, C fields)
2. Public key -- the applicant's public key that will be embedded in the certificate
3. Requested extensions -- additional attributes like Subject Alternative Names
4. Signature -- the CSR is signed with the applicant's private key, proving they possess the corresponding key pair

Generating a CSR with OpenSSL

A typical CSR generation command:

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

For CSRs with SANs, you need an OpenSSL configuration file specifying the subjectAltName extension, or use the -addext flag:

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

CSR vs. Certificate

CSR Review Best Practices

The single most common CSR mistake is forgetting to include the Common Name in the Subject Alternative Names. Since Chrome 58 (released in 2017), browsers ignore the CN field entirely for hostname validation and only check SANs. If your CSR has CN=www.example.com but no DNS:www.example.com SAN entry, the issued certificate will produce hostname mismatch errors in every modern browser. Always make sure every domain that should be covered appears as a SAN entry, including the CN itself.

Another frequent issue is generating a CSR with a key that is too small. CAs will not issue certificates for RSA keys smaller than 2048 bits, and some compliance frameworks require 4096-bit RSA or ECDSA P-384. If your automation tools have default key sizes, check them before deploying to production. Regenerating a CSR with a larger key is simple; discovering the problem after the certificate has been issued and deployed is not.

For teams using infrastructure-as-code tools like Terraform or Ansible to generate CSRs, build a verification step into your pipeline. Have the CSR parsed and validated automatically before it is submitted to the CA. This catches configuration drift, incorrect variable substitutions, and template errors that would otherwise result in certificates with wrong domains or missing SANs. A one-line check that verifies the CSR's CN and SAN list matches the expected values can save hours of troubleshooting.

Frequently Asked Questions

Can a CA change what is in my CSR? Yes. The CA controls what goes into the final certificate. For DV certificates, CAs typically strip organization fields and only keep the CN and SANs. For OV/EV certificates, the CA verifies and may adjust organization details. The CA always sets the validity period, serial number, and issuer fields. Reviewing both your CSR and the issued certificate is good practice.

Why does my CSR show SHA-256 with RSA but I generated it with an ECDSA key? The signature algorithm in the CSR reflects how the CSR itself was signed, which depends on your key type. An ECDSA key produces ecdsa-with-SHA256 or similar. If you see sha256WithRSAEncryption, your key is RSA. Check the Public Key section to confirm the algorithm and key size match your expectations.

Do I need to include SANs in the CSR, or can the CA add them? This depends on the CA. Most modern CAs allow you to specify SANs during the ordering process, even if they are not in the CSR. However, including SANs in the CSR is best practice because it documents your intent and is required by some CAs. Always verify the issued certificate includes all expected SANs.

How do I verify that a CSR and a private key match? Extract the public key from both the CSR and the private key, then compare. With OpenSSL: openssl req -in csr.pem -noout -pubkey and openssl pkey -in key.pem -pubout. If the output is identical, the CSR was generated with that private key. The Public Key Extractor can also help with this comparison.

What is the difference between PKCS#10 and a Certificate Signing Request? They are the same thing. PKCS#10 (RFC 2986) is the formal standard that defines the CSR format. When tools refer to a "PKCS#10 request" or a "CSR," they mean the same data structure. The PEM header -----BEGIN CERTIFICATE REQUEST----- is used for PKCS#10 CSRs.

Can I reuse a CSR after the certificate expires? Technically yes, if you still have the corresponding private key. However, best practice is to generate a new key pair and CSR for each renewal. This limits the exposure window if the private key was compromised at some point during the previous certificate's lifetime.

Related Tools

• X.509 Certificate Viewer - View the issued certificate to compare against the original CSR
• Public Key Extractor - Extract the public key from both CSR and certificate to verify they match
• SAN Extractor - Extract SANs from the issued certificate to confirm all requested domains are covered
• Certificate Fingerprint Generator - Generate fingerprints for the issued certificate
• Certificate Expiry Checker - Check the validity period of the issued certificate