Why use this analyzer?
Validate what will appear on your certificate before sending it to a Certificate Authority (CA). Detect a missing SAN, a weak key, an outdated algorithm, or dubious IDN encoding. Save time during onboarding or renewal by reading the useful fields right away.
What is a CSR?
A Certificate Signing Request is a PEM-format text file containing:
- Your public key (RSA or EC)
- Identity information: subject (CN, O, OU, L, ST, C) and SANs
- A signature made with your private key to prove possession
The CSR is sent to a CA (Let's Encrypt, DigiCert, GlobalSign, Sectigo...) which issues the certificate if validation passes (DV, OV, or EV).
When to generate a CSR?
| Use case | Description |
|---|---|
| New certificate | Creating a TLS certificate for web server, API, MTA |
| Renewal | Renewing an existing certificate with a new key pair |
| Adding SANs | Adding a new subdomain or FQDN to the certificate |
| RSA to EC migration | Switching to EC key for better performance |
| Standardization | Harmonizing fields across a heterogeneous infrastructure |
What should a good CSR contain?
Required fields
- SAN (Subject Alternative Names): list of all covered names, including the bare domain if needed. Without SANs, many CAs will reject.
- Public key: RSA 2048 bits minimum (ideally 3072) or EC P-256/P-384
- Signature: SHA-256 recommended (SHA-1 rejected)
Optional fields
- Subject CN: often ignored by modern CAs, but keep it for compatibility
- O, OU, L, ST, C: useful for OV/EV, unnecessary for DV
- Key Usage / Extended Key Usage: depending on your specific needs
Important: A CN alone is no longer sufficient. SANs are mandatory for most CAs.
OpenSSL examples
RSA 3072 CSR with SANs
san.cnf file:
[ 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
Command:
openssl req -new -newkey rsa:3072 -nodes -keyout site.key -out site.csr -config san.cnf
EC P-256 CSR with SANs
openssl ecparam -name prime256v1 -genkey -noout -out site.key
openssl req -new -key site.key -out site.csr -config san.cnf
Internationalized Domain Names (IDN)
Use punycode (xn--...) in SANs to avoid encoding surprises.
Common errors
| Error | Impact | Solution |
|---|---|---|
| Missing SANs | Certificate covers fewer names than expected | Add all domains in the [alt] section |
| RSA 1024 or SHA-1 | Likely rejection by CA | Use RSA 2048+ and SHA-256 |
| Private key exposed | Security compromise | Never paste private key online |
| Incorrect IDN encoding | Domain not recognized | Use exact punycode |
| Wildcard without bare domain | *.example.com doesn't cover example.com | Add both in SANs |
Best practices
- Generate key pair server-side and keep private key off any shared system
- Prefer EC P-256/P-384 or RSA 3072+ for new deployments
- Limit the SAN list to what is actually needed
- Keep a log: date, subject, SANs, key size, responsible person
- Test the CSR after generation to avoid back-and-forth with the CA
Privacy
Your CSR is sent to the CaptainDNS API only to be decoded and displayed. Content is not stored. No field is logged in clear text. Only anonymous technical metrics are recorded (processing time, size, key type, algorithm) for availability monitoring.