CSR Decoder Guide: Checking a Certificate Signing Request

What this tool does

The CSR Decoder reads a PKCS#10 Certificate Signing Request and shows its contents: the subject distinguished name, the Subject Alternative Names, the public key's type and size, and the signature algorithm. It parses the request in your browser using the same DER parser behind the certificate decoder.

What is in a CSR

A CSR is what you send a certificate authority to request a certificate. It contains your subject details (organisation, common name), your public key, any Subject Alternative Names you want on the certificate, and a signature proving you hold the matching private key. The private key never appears in the CSR — it stays on your server — which is why a CSR is safe to paste here or hand to a CA.

What to check before submitting

• Common Name and SANs. Browsers match hostnames against SANs, not the CN, so every name you need — apex domain, www, any subdomains — must be in the SAN list. A missing SAN is the most common reason for a reissue.
• Key type and size. Use RSA 2048+ or an EC key on P-256/384. Anything smaller will be rejected.
• Subject fields. For OV/EV certificates the organisation details must be accurate; for domain-validated certs most CAs ignore them.

Where a CSR fits

The usual flow is: generate a key pair and CSR on your server, paste the CSR to your CA, receive the signed certificate, and install it alongside the private key. If you already have a certificate and need to renew it, the certificate-to-CSR generator can regenerate a matching request, and the certificate decoder inspects the issued certificate.

Privacy

The CSR is parsed locally in your browser and never uploaded. Because a CSR carries only public information, inspecting one here discloses nothing secret — but as always, generate and handle certificate material on a machine you trust.

Ready to try it? Open the CSR Decoder →