CSR Parser

Why use this parser?

Validate what will appear on your certificate before sending it to an authority.
Detect a missing SAN, a key that's too short, a weak algorithm, suspicious IDN encoding.
Save time during onboarding or renewal by immediately reading the useful fields.

What is a CSR?

A Certificate Signing Request is a text file in PEM format that contains:

your public key
subject identity and SAN information
a signature made with your private key to prove possession

The CSR is transmitted to a CA—Let's Encrypt, DigiCert, GlobalSign…—which issues the certificate if verification passes: DV, OV, EV.

When to generate a CSR?

Creating or renewing a TLS certificate for web server, API, MTA
Adding a new SAN subdomain, new FQDN
Switching from RSA to EC for better performance
Standardizing a heterogeneous infrastructure where fields are inconsistent

What should a good CSR contain?

Subject CN sometimes ignored by modern CAs, keep it but don't rely on it alone
SAN Subject Alternative Name the list of all covered names, including the bare domain if necessary
Public Key type RSA 2048 min, ideal 3072 or EC P-256/P-384
Signature SHA-256 recommended
Optional Key Usage and Extended Key Usage according to your needs

Reminder
Without SAN, many CAs refuse. A CN alone is no longer sufficient.

Instructions

Paste the complete CSR between -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST-----.
Click Analyze CSR.
Read the summary: subject, SAN, key type and size, algorithm, fingerprints.
Correct and regenerate if something's blocking.

Useful OpenSSL examples

RSA 3072 CSR with SAN

# san.cnf
[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.example.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.example.com
DNS.2 = example.com

openssl req -new -newkey rsa:3072 -nodes -keyout site.key -out site.csr -config san.cnf

EC P-256 CSR with SAN

openssl ecparam -name prime256v1 -genkey -noout -out site.key
openssl req -new -key site.key -out site.csr -config san.cnf

IDN

Use punycode xn--… in SANs to avoid surprises.

Troubleshooting and common errors

Missing SANs the certificate will cover fewer names than expected
RSA 1024 or SHA-1 likely rejection
Private key exposed never paste the private key here or in a ticket
Fancy field selectors O, OU, L, ST, C useless in DV and sources of inconsistency in OV/EV
Incorrectly encoded IDN use exact punycode
Wildcard *.example.com also add example.com if you want to cover the bare domain

Best practices

Generate the key pair server-side and keep the private key out of any sharing
Prefer EC P-256/P-384 or RSA ≥ 3072 for new deployments
Limit the SAN list to what is actually useful
Keep a log: date, subject, SAN, key size, originating person
Test reading the CSR after generation to avoid a round trip with the CA

Privacy commitment

Your CSR is sent to the CaptainDNS API only to be decoded and displayed.
The content is not retained. No field is logged in clear text.
Only anonymous technical metrics are recorded: processing time, size, key type, and algorithm for availability monitoring.