CSR Decoder for PKCS#10 Certificate Requests

How to use the csr decoder

1. Create a CSR with openssl req -new -key server.key -out server.csr or your server software, then open the .csr file in a text editor.
2. Copy everything from -----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST----- and paste it into the box.
3. Check that the common name and the Subject Alternative Names list every hostname you want on the certificate.
4. Check the key size and signature algorithm, then submit the CSR to your CA.

What a PKCS#10 request contains

A certificate signing request is defined in PKCS#10 (RFC 2986). It has three parts: the request information, a signature algorithm identifier and a signature made with the private key that matches the public key inside the request. The signature proves you hold that key without revealing it.

Where the Subject Alternative Names are stored

SANs are not part of the subject. They sit in an attribute called extensionRequest (OID 1.2.840.113549.1.9.14), which wraps a normal X.509 extensions list. This csr decoder opens that attribute and prints the subjectAltName entries as DNS names, IP addresses, emails and URIs.

If the row says no extensionRequest attribute, the request names a host only in its common name. Most public CAs ignore the CN for validation and ask for a SAN list, and browsers match hostnames against SANs, so regenerate the request with a SAN section. With OpenSSL 1.1.1 or later you can add -addext "subjectAltName=DNS:example.com,DNS:www.example.com" to the openssl req command.

Worked example: a request for shop.acme.example

The default example is a request from Acme Ltd. The decoder returns the subject C=GB, ST=London, L=London, O=Acme Ltd, OU=Web, CN=shop.acme.example and the common name shop.acme.example. It lists four SANs: DNS:shop.acme.example, DNS:www.acme.example, IP Address:198.51.100.7, email:ops@acme.example. The key is RSA with 2048 bits (exponent 65537), signed with sha256WithRSAEncryption.

The second example is an EC P-256 request with no extensions at all. It decodes to a subject and a key but shows that no SAN was requested, which is the usual reason a CA asks you to resubmit.

Checking a CSR before you submit it

Reviewing the request takes seconds and avoids a reissue. Check these points:

• Names: every hostname must appear as a DNS SAN. A wildcard such as *.example.com covers one label only.
• Key size: RSA 2048 is the usual minimum. Weaker keys are refused by public CAs.
• Signature algorithm: sha256WithRSAEncryption or an ECDSA with SHA-256 or SHA-384 is fine. MD5 and SHA-1 signatures are flagged as a warning row.
• Key type: check that your CA and server software accept the EC curve you chose. P-256 and P-384 are widely supported.

To confirm the signature itself, run openssl req -in server.csr -noout -verify. This page reads the structure but does not recompute the signature.

Mistakes that cause rejected requests

The most common one is pasting the wrong file. A private key block starts with BEGIN PRIVATE KEY and must never be shared, and a CSR never contains one. If the box shows an error about the label, check that the block says CERTIFICATE REQUEST. Some tools write NEW CERTIFICATE REQUEST, which is also accepted.

Other frequent errors are a CSR created for the wrong domain, a country code of more than two letters, and a binary .der request that needs converting. For binary files use the certificate converter. Once the CA returns the signed certificate, inspect it with the SSL certificate decoder and track its renewal date with the expiry checker.

Worked examples