CSR Decoder and Validator

Decode a certificate signing request locally to check the subject, SANs, key type and strength, and verify its self-signature, before a CA rejects it.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Certificate signing request Decoded and signature-verified in your browser. Never uploaded.

Or drop a .csr file

Read locally.

It verifies the signature before calling anything valid

A certificate signing request is self-signed by the private key it requests a certificate for. That signature is the only thing in the request proving the requester actually holds the key - it is the entire security property of the format.

Most online CSR decoders never check it. They parse the fields and print them, so a request with a corrupted or substituted signature displays as perfectly healthy, and you find out when the CA rejects it with a message that explains nothing. This tool verifies the signature with the Web Crypto API before showing a green result, and when it cannot verify - an algorithm the browser does not expose, for instance - it says so clearly rather than staying quiet.

The Common Name is not what browsers check

This is the single most common reason a correctly issued certificate does not work. Browsers have ignored the Common Name for hostname validation since 2017. They validate against Subject Alternative Names exclusively.

A CSR with CN=example.com and no SAN extension can produce a certificate that no browser will accept for example.com - unless the CA quietly adds the SAN for you. Many do. Relying on it is a gamble, and the tool reports both the missing-SAN case and the subtler one where SANs exist but the CN is not among them.

The fix is to request them explicitly:

openssl req -new -key key.pem -out request.csr \
          -subj "/CN=example.com" \
          -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

A CSR only requests extensions

Extensions in a CSR are a request, not an instruction. The certificate authority decides what actually goes into the certificate and routinely overrides or ignores what you asked for - key usage and basic constraints are almost always set by the CA's own profile regardless. The tool lists requested extensions under that heading for exactly this reason: seeing them here does not mean you will get them.

What else it checks

Key strength. RSA below 2048 bits will be refused by every public CA. EC keys are checked for a curve that CAs actually issue against - P-256 and P-384.
The public exponent. Essentially every RSA key uses 65537. Anything else has historically been associated with implementation weaknesses and some CAs reject it, so it is flagged.
Signature algorithm. A CSR signed with SHA-1 or MD5 will be rejected outright - both are practically collidable.
Subject structure. A missing CN, or more than one, both cause rejections.

Hardened parsing

A CSR is DER, and DER states its own lengths - which means a malformed or hostile file states whatever it likes. The parser here validates every length against the remaining buffer before using it, caps nesting depth, refuses indefinite-length encoding (which DER forbids), and reports trailing content after a complete structure rather than ignoring it. A truncated or corrupted request produces a clear message instead of a crash or a hang.

Everything happens in your browser. A CSR is not itself secret, but it is generated beside a private key and there is no reason for it to travel.

Frequently asked questions

Why does it say the signature is invalid when the CSR looks fine?

Because the fields decoding correctly and the signature verifying are different things. An invalid signature means the file was modified after signing or is corrupted - most often from copy-paste through something that altered whitespace or line endings. Regenerate it rather than trying to repair it.

Do I need SANs if my CN is correct?

Yes. Browsers ignore the CN for hostname validation and have done since 2017. Some CAs add a SAN matching the CN for you, but relying on that is a gamble you do not need to take.

Will the CA honour the extensions I requested?

Often not. A CSR requests extensions; the CA decides. Key usage and basic constraints are almost always set from the CA profile regardless of what you asked for.

Is my CSR uploaded?

No. Decoding and signature verification both happen in your browser using the Web Crypto API.

It says the algorithm is unsupported for verification.

Some signature algorithms are not exposed by the browser Web Crypto API. The fields still decode, but the tool will not claim the signature is valid when it has not checked it. Use openssl req -in request.csr -verify -noout instead.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.