CSR Parser

Why analyze a CSR before submitting it?

A CSR decoder shows fields. It answers "what is in this file", never the question you actually face before paying for a certificate: will my certificate authority accept it, and if not, why.

The gap is measurable. A Common Name missing from the SANs, a wildcard placed on *.co.uk, an underscore in a DNS name, a .local name, a private IP address in a SAN, or no SAN at all: these are all requests that a public authority rejects, and that the decoders on the market display without a word.

This parser decodes the CSR in full, then checks every measured fact against the CA/Browser Forum Baseline Requirements and the applicable RFCs. It returns a three-state verdict, compliant, warning or non-compliant, with the findings and their source. The catalog holds 59 codes; how many checks actually run depends on the CSR analyzed.

Three uses that keep coming back:

• Before submission: fix the blocking items and send the right CSR just once.
• When the certificate arrives: confirm it came from this CSR, public key fingerprint in hand.
• When taking over a legacy PKI: spot internal names, short keys and prohibited fields.

What a CSR contains

A Certificate Signing Request is an ASN.1 object defined by RFC 2986, DER-encoded then carried as base64 inside a PEM envelope. It holds three things:

• a public key, RSA or elliptic curve, and that alone;
• the requested identifiers: the subject (CN, O, L, ST, C) and, inside a PKCS#9 attribute named extensionRequest, the wanted extensions including the SANs;
• a signature produced with the matching private key.

SANs are therefore not a top-level field: they travel inside an attribute. That is why an incomplete openssl configuration produces a CSR without a single SAN and nothing complains.

What your certificate authority really does with the CSR

Here is the point almost every decoder misses: the authority rebuilds the certificate, it does not copy the CSR. It generates the authorityInformationAccess, the authorityKeyIdentifier, the certificatePolicies, the extKeyUsage and even the subjectAltName of the issued certificate itself. One field alone is carried over byte for byte: the SubjectPublicKeyInfo, your public key and its algorithm identifier.

That dictates the severity of every finding, and it is the central calibration of the tool. Content only becomes blocking if it makes a compliant certificate impossible: key outside the profile, compromised key, illegal identifier, or a breach of RFC 2986 by the CSR itself. Anything the authority overwrites or ignores, an organizational unit or an exotic extension, tops out at a warning.

What the signature proves, and what it does not

The signature on a CSR establishes one thing: at build time, the author held the private key matching the public key, and the subject, key and attributes triplet has not moved since. It proves no domain control, no authority on the requester's part, no freshness (PKCS#10 carries no timestamp) and no exclusivity: the key may well be sitting in a public repository.

An invalid signature therefore does not stop the analysis, it is one finding among others, and the cause is often harmless: truncation on copy and paste, a CSR re-encoded by a hosting portal. The tool distinguishes three states rather than two, valid, invalid and unverifiable; it never accuses a CSR of tampering when it simply could not verify it.

The rejections that decoding alone never shows

The CN must appear in the SAN list

The Common Name is optional and discouraged in current profiles. But if it is present, it must repeat one of the subjectAltName values exactly: a CN that appears nowhere in the SANs makes the certificate non-compliant.

The neighboring case is more common still, the CSR with no SAN at all. With a CN, it depends on a charitable rebuild by the authority, which you should never rely on. With neither CN nor SAN, the authority has nothing to validate and rejection is certain.

The two layers of rules on wildcards

The syntax layer comes from RFC 9525: one wildcard only, and it must be the whole content of the leftmost label. *.captaindns.com is valid; *.*.captaindns.com and www*.captaindns.com are not, and a compliant client must ignore the name. The certificate would be issued, then unusable.

The policy layer comes from the Baseline Requirements: an authority must refuse a wildcard placed on a public suffix from the ICANN section, *.co.uk for example. On the private section of the same list, refusal is only a recommendation, hence a plain warning.

A reminder that often gets forgotten: a wildcard descends one level only. *.captaindns.com covers neither captaindns.com nor a.b.captaindns.com.

Internal names have not been issuable since 2015

server.local, intranet.corp, nas.lan, localhost, a single label with no dot, or a TLD absent from the root zone: those are internal names. Issuing them has been forbidden since 1 November 2015 and the existing certificates were force-revoked on 1 October 2016. They still turn up in CSRs coming from old internal PKIs, recycled for use with a public authority.

Same logic for reserved IP addresses in a SAN, whether they fall under RFC 1918, loopback, link-local, CGNAT or ULA: an authority does not validate what it cannot reach. New since 15 March 2026: a name ending in .in-addr.arpa or .ip6.arpa is forbidden too.

The organizational unit has vanished from certificates

The organizationalUnit field has been prohibited since 1 September 2022, under ballot SC047v2 adopted on 29 June 2021; the common reference to "ballot SC62" is inaccurate. The authority does not reject the CSR over it, it strips the field, hence a warning.

An email address in the subject is deprecated by RFC 5280 and has no legitimate place in a server TLS certificate. And a counter-intuitive point: an empty subject is compliant, and even modern. The domain validation profile accepts only the country, optional, and the Common Name, discouraged.

Key sizes, algorithms and keys already compromised

RSA 2048 remains compliant: 3072 bits is a recommendation aimed at 2030, flagged as information. A SHA-1 signature is not blocking under the Baseline Requirements, whose anti-SHA-1 clause targets objects signed by an authority and not by the subscriber; it is classed as a warning, with the caveat that authorities have refused it in practice since 2016.

Two checks go further. They are the only places in the Baseline Requirements stating that the authority must reject the request:

• ROCA (CVE-2017-15361): RSA keys produced by a library widespread in smart cards and TPMs have a recognizable structure that collapses their entropy. Detection factors nothing: it is a fingerprint test on the modulus.
• Debian weak keys (CVE-2008-0166): between September 2006 and May 2008, a broken random generator shrank the key space to a few tens of thousands of values per size. The list ships with the service and is consulted offline.

In both cases, the whole key pair has to be regenerated: reusing the same key in a new CSR would carry the weakness over.

The SPKI fingerprint, the one that ties everything else together

Every decoder displays a "fingerprint" of the CSR. It is the digest of the whole file: it changes if you regenerate the CSR with the same key, and it bears no relation to the certificate you will receive.

The fingerprint that serves is that of the SubjectPublicKeyInfo, defined by RFC 7469: the SHA-256 digest of the DER-encoded public key structure. Since it is the only field copied byte for byte, the same value shows up in the CSR, in the issued certificate and in the matching private key, and it survives a reissuance.

Three immediate uses: match a received certificate to its CSR, without comparing subjects the authority has rewritten anyway; check locally that your private key is the right one, with the command given below; build a DANE 3 1 1 record, whose selector 1 is exactly this fingerprint, which the DANE/TLSA checker then verifies in DNS. The fingerprint is published in hexadecimal and in base64.

Compare the CSR with the deployed certificate

Optional, unchecked by default: give a host, and the parser fetches the certificate it actually serves then compares the two SPKI fingerprints. Three outcomes, same key, different key, or unreachable host, the last being the most frequent since a CSR is analyzed before issuance.

This is the only network path in the tool: box unchecked, no outbound connection. The result never enters the compliance verdict, because what is deployed elsewhere says nothing about the validity of a request, and nothing from the CSR is sent to the host.

To judge the deployed certificate itself, chain of trust and expiry included, the dedicated tool is the SSL Certificate Checker. Then comes certificate lifecycle management, all the more so as the validity period drops to 47 days by 2029.

Useful openssl commands

A san.cnf file, without which openssl produces a CSR with no SAN:

[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.captaindns.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.captaindns.com
DNS.2 = captaindns.com

# RSA 3072
openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf

# ECDSA P-256
openssl ecparam -name prime256v1 -genkey -noout -out captaindns.key
openssl req -new -key captaindns.key -out captaindns.csr -config san.cnf

Compute the SPKI fingerprint of the CSR, of the received certificate and of the private key, then check that all three match, without sending anything anywhere:

openssl req  -in captaindns.csr -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl x509 -in captaindns.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in captaindns.key -pubout       | openssl pkey -pubin -outform DER | openssl dgst -sha256

For an internationalized domain, enter the punycode form (xn-- prefix) in the SANs: the parser shows the Unicode form alongside and never invalidates a correct xn-- label.

Privacy

Never paste your private key, here or anywhere else: a CSR carries only the public key. A private key PEM header is detected before anything is sent and the analysis is refused on the spot. If the key has already been pasted into a web form, treat it as compromised and regenerate the pair.

The CSR itself is not a secret: it carries identifiers meant to appear in a certificate, published afterwards in the Certificate Transparency logs. It is processed in memory to be analyzed and displayed. One exception: the value of the challengePassword attribute is never returned, displayed or logged; only its presence is reported.

FAQ - Frequently asked questions

Q: What is a CSR (Certificate Signing Request)?

A: A PKCS#10 file, carried in PEM, holding your public key, the requested identifiers (subject and SANs) and a signature produced with the matching private key. It never contains the private key. You send it to a certificate authority, which verifies your control of the domains then issues the certificate.

Q: Why does a certificate authority reject a CSR?

A: Most often a Common Name missing from the SANs, a malformed wildcard or one placed on a public suffix, an illegal character in a DNS name (the underscore leading the pack), an internal name in .local or .corp, a private IP address in a SAN, a key under 2048 bits, or no SAN at all.

Q: Must the Common Name appear in the SANs?

A: Yes, as soon as it is present: the Baseline Requirements demand that it repeat one of the subjectAltName values exactly. The simplest route is to leave it empty, since browsers have read the SANs alone for years.

Q: My CSR is signed with SHA-1, is that blocking?

A: Not under the Baseline Requirements: the clause banning SHA-1 targets objects signed by an authority private key, whereas a CSR is signed by the subscriber. The tool classes it as a warning. In practice, public authorities have refused SHA-1 CSRs since 2016, so regenerate with SHA-256. MD5 and MD2 are blocking.

Q: Should I fill in the O, OU, L and ST subject fields?

A: No for a domain validation certificate: the profile accepts only the country, optional, and the Common Name, discouraged. An empty subject is perfectly compliant. The organizational unit is even prohibited since 1 September 2022.

Q: What is the SPKI fingerprint for?

A: It is the SHA-256 digest of the public key structure, the only field an authority copies byte for byte from the CSR into the certificate. It proves that a CSR, a received certificate and a private key carry the same key, and it serves as selector 1 in a DANE TLSA record. The fingerprint other decoders publish covers the whole file and allows none of those matches.

Q: Does the certificate already online match my CSR?

A: Tick the comparison option and give the host. The parser fetches the certificate served and compares its SPKI fingerprint with the one from the CSR: same key, different key, or unreachable host. That comparison never influences the compliance verdict and sends nothing from the CSR to the host queried.

Q: How do I generate a CSR with SANs using openssl?

A: Create a configuration file listing DNS.1, DNS.2 and so on, then run openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf. For an elliptic key, first generate the key with openssl ecparam -name prime256v1 -genkey -noout, then call openssl req -new -key. Without that file, openssl produces a CSR with no SAN.

Complementary tools

Useful resources

• RFC 2986 - certification request syntax (PKCS#10 structure of the CSR)
• RFC 9525 - service identity verification (wildcard rules, replaces RFC 6125)
• RFC 7469 - public key pinning (normative definition of the SPKI fingerprint)
• CA/Browser Forum - Baseline Requirements (TLS certificate issuance rules)