Guide
Checking a certificate signing request before you submit it
To get a TLS certificate, you generate a key pair and send a certificate authority a request, a CSR, that contains your public key, the names you want certified and a signature made with your private key. A wrong name or a weak key in that request costs time, and sometimes money, because the authority signs what you send. Decoding the CSR first takes seconds and catches the common mistakes.
What a CSR contains
A PKCS#10 request, defined in RFC 2986, has three parts: the information to be certified (a version, the subject name, the public key and a set of attributes), the algorithm used to sign it, and the signature. Extensions such as Subject Alternative Names travel inside an attribute called extensionRequest. The private key does not appear anywhere in it, so a CSR is safe to share with the authority and with this page.
A worked example
The sample is an elliptic-curve request made with OpenSSL for api.example.org. The summary reads: common name api.example.org, key EC prime256v1, two names in the SAN list. The details give the subject C=DE, O=Test GmbH, CN=api.example.org, Subject Alternative Names api.example.org and api2.example.org, public key algorithm id-ecPublicKey on curve prime256v1 (P-256), signature algorithm ecdsa-with-SHA256 and version v1. The page confirms: “The request’s signature is valid: whoever made it holds the private key that matches the public key inside.” The review lists “Good: Key strength is acceptable”.
What the checks catch
Look first at the names. Every host the certificate must cover should appear in the SAN list; a wildcard such as *.example.org covers one label only and does not match the bare domain. Check the key: RSA below 2048 bits is rejected by public authorities, and the review warns about it. Check the signature algorithm: SHA-1 signatures are no longer acceptable. A failed signature check means the request was damaged after it was made, for example by an editor changing a line.
Signature verification
The proof of possession works because only the holder of the private key could have signed the exact bytes of the request. The page re-computes that check with the public key from the request, using the browser’s Web Crypto API. If it passes, the request is internally consistent. It says nothing about who you are; that is for the authority to establish through domain or organisation validation.
Common mistakes
Typos in the organisation name, a missing country code, a common name that is an IP address, or generating the request on one machine and the key on another. If the authority returns a certificate that does not match your key, the request was made with a different key than the one on the server. Compare the public key in the returned certificate with the key on your server before you install it.
Limits
The page cannot know a certificate authority’s policy, which fields it will copy, or how it validates ownership. It supports PKCS#10 requests only. The decoding runs in your browser and nothing is sent.
Related tools
- SSL Certificate Decoder reads the certificate you receive in return.
- ASN.1 Decoder shows the raw structure of the request.
- RSA and Ed25519 Key Pair Generator makes a key to build a request from.
- JWK to PEM Converter converts the public key to other formats.
Checked against the current version of the CSR Decoder on .