Certificate Signing Request Decoder
Paste a CSR and see exactly what you’re sending to a certificate authority — subject, public key, requested domains, signature algorithm and the problems that will bite you later.
A Certificate Signing Request (CSR) is the PKCS#10 document you hand to a CA when ordering an SSL/TLS certificate: your identity (the subject DN), the public key to be certified, and — usually — the domains you want covered in a Subject Alternative Name extension. This decoder parses the full ASN.1/DER structure in your browser and shows every field in plain English: subject, public key details (RSA modulus and exponent, EC curve, Ed25519), requested domains (DNS names, IPs, emails from the SAN extension), the signature algorithm, plus a findings panel that flags the mistakes that actually break deployments — missing SANs, weak RSA keys, deprecated signature algorithms.
Decode a CSR
Paste the output of openssl req -new, or the CSR file from your server, control panel or load balancer (nginx, HAProxy, Apache). Raw Base64 without the -----BEGIN CERTIFICATE REQUEST----- headers works too.
Overview
| Version | |
|---|---|
| Signature algorithm | |
| Public key | |
| Requested domains |
Subject (who the certificate is for)
The Distinguished Name (DN) — the identity fields you typed when generating the CSR. Browsers no longer display or verify most of these; they matter to the CA, to internal tools and for auditing.
Public key
Requested domains (Subject Alternative Name)
What the certificate will actually cover. This is what browsers and clients check — not the Common Name.
Findings
Automated checks for the problems that most often break certificate deployments.
Export
What is a CSR, and what’s inside it?
A Certificate Signing Request is a PKCS#10 document (RFC 2986) that binds three things together: who you are (the subject Distinguished Name), which public key should be certified, and a signature made with the matching private key. That last part is the proof of possession — when the CA verifies it, they know the entity submitting the CSR actually holds the private key, so they can safely certify the public half.
The DER structure looks like this:
The private key is never in the CSR — only its public half. That’s why it’s safe to paste a CSR into this page, or email it to a CA, or open it in any tool: the file alone can never unlock anything.
The attributes field is where SANs live
The attributes [0] field carries extensionRequest (OID 1.2.840.113549.1.9.14): a nested DER blob of the X.509 extensions you want in the final certificate — most importantly subjectAltName (OID 2.5.29.17), which lists every DNS name, IP address and email the certificate should cover. If you generate a CSR without it, the CA issues a certificate with no SANs and modern browsers will refuse to trust it for any hostname.
How to generate a CSR (OpenSSL)
One-liner (OpenSSL 1.1.1+), with SANs:
Multiple SANs, or older OpenSSL — use a config file:
Then openssl req -new -key server.key -out server.csr -config csr.cnf. Keep server.key safe — the private key stays on your machine for the whole process and is what you’ll install next to the issued certificate.
Verify it before sending:
Why Subject Alternative Names matter
Historically, browsers matched the hostname against the certificate’s Common Name. That was ambiguous (which of several names wins?), so every major browser vendor agreed to deprecate it: since Chrome 58 / Firefox 60 / Safari 9.1 (2015–2017), the CN is ignored for hostname verification and only SAN entries count. The practical consequences:
- One domain, one SAN entry. A certificate for example.com and www.example.com needs both listed — the CN doesn’t cover either on its own.
- Wildcards are SAN entries too: *.example.com covers one label level only (api.example.com, not a.b.example.com).
- IP addresses need IP SANs (e.g. internal load balancers) — a DNS name will never validate an IP.
- Email certificates (for S/MIME) use email: entries in the same extension.
The findings panel above flags a missing SAN, a CN that doesn’t match any SAN entry, and SANs with typos you can spot at a glance.
Key algorithm recommendations
| RSA 2048–4096 | The safe default everywhere. 2048-bit is the current minimum; 3072 or 4096 gives more headroom at a small handshake cost. Below 2048 is a hard no. |
|---|---|
| ECC P-256 | The modern favourite for TLS: ~128-bit security, smaller keys and certificates, faster handshakes on mobile. Equivalent strength to RSA 3072. |
| ECC P-384 | ~192-bit security for long-lived or high-value certificates (equivalent to RSA 7680). |
| Ed25519 | Fully supported by current browsers and clients; very fast signatures. A great choice where you control both ends. |
| DSA | Deprecated (RFC 8418) — do not use for new certificates. |
The signature algorithm on the CSR itself (e.g. SHA-256 with RSA, ECDSA with SHA-256, EdDSA) just protects the CSR in transit to the CA — it does not determine the certificate’s strength, but SHA-1-signed CSRs are a sign of old tooling worth updating.
Suggested
