CSR Decoder (PKCS#10)

How to use

1. Paste the CSR, or drop the .csr or .pem file onto the box. It begins with -----BEGIN CERTIFICATE REQUEST-----.
2. Check the SAN list first — every hostname the certificate must cover has to appear there, including the one in the Common Name.
3. Confirm the self-signature verifies; if it does not, regenerate the request rather than sending it.
4. Read the key size and signature algorithm: a public CA needs at least 2048-bit RSA (or any EC curve) and a SHA-256 or better signature.
5. Resolve anything in amber before submitting, because a CA rejection usually costs a round trip of hours.

Frequently asked questions

Why does a certificate need a SAN if it already has a Common Name?

Because clients stopped looking at the Common Name. RFC 2818 deprecated using it for hostname matching in 2000, Chrome dropped support in version 58 in 2017, and the other browsers followed; the CA/Browser Forum baseline requirements now oblige a CA to put every name in the subjectAltName extension regardless. A CSR whose hostname appears only in the CN will either be rejected by the CA or produce a certificate that every modern browser refuses with ERR_CERT_COMMON_NAME_INVALID. The CN is still shown by tooling, which is exactly what makes the mistake easy to miss.

What does the self-signature on a CSR prove?

That whoever produced the request holds the private key matching the public key inside it. The request is signed with that key, over its own contents, so a CA can verify it with nothing but the request — this is what stops someone submitting a CSR containing your public key and getting a certificate for your name. It proves nothing about domain ownership, which the CA checks separately. If the signature does not verify, the file was altered after signing, which usually means it was corrupted in transit or edited by hand.

Is it safe to paste a CSR here?

Yes. A CSR carries only public information — the names you are requesting and the public half of your key pair — and is meant to be handed to a CA anyway. Even so, this page never sends it anywhere: the ASN.1 parsing and the signature verification both run in your browser via WebCrypto, which you can confirm by loading the page, disconnecting from the network and pasting a request. The private key is a different matter entirely: never paste one anywhere, and if you do here, the tool refuses it.

Why is the signature sometimes not checked?

Because verification needs the browser to import the public key, and WebCrypto supports a fixed set of algorithms. RSA and ECDSA on the NIST curves work everywhere; Ed25519 works in recent browsers and is skipped in older ones. When the key type cannot be imported the tool says the signature was not checked rather than implying it passed — an unchecked signature and a valid one are very different things, and conflating them would be the one genuinely dangerous thing this tool could do.

Can I decode a certificate here too?

No — a certificate and a certificate signing request are different structures, and this tool reads PKCS#10 requests only. A CSR is what you send to a CA; a certificate is what comes back, and it carries an issuer, a validity window and the CA's signature, none of which exist in a request. Paste a -----BEGIN CERTIFICATE----- block into the certificate decoder instead.

What is the challenge password for?

It is an optional attribute from the original PKCS#10 specification, meant as a shared secret that would let you later ask the CA to revoke the certificate. Almost no public CA uses it now — revocation is handled through the account you authenticated with — but some enterprise and SCEP enrolment flows still require one, and Microsoft's certificate services will read it. If it is set, this tool shows it, which is worth knowing since it travels in the request in the clear.

Related tools