CSR Decoder

What a CSR holds, and what it does not

A certificate signing request carries three things: the subject you are asking to be named as, the public half of your key pair, and any extensions you are requesting - most importantly the subject alternative names. It is signed with your private key, which proves to the CA that you actually hold the key you are asking them to certify.

It does not contain the private key, and nothing in it can be used to derive one. That is why a CSR is not a secret in the way a key is, and why it is reasonable to paste one into a tool. It is also not nothing: it describes hostnames, an organisation, sometimes internal naming conventions, so it is worth knowing whether the decoder you are using sends it anywhere. Many do, because most of them are run by companies that sell certificates.

It is also worth knowing how little of a CSR survives. The CA validates the names, then issues a certificate using its own serial number, validity dates, issuer, and its own view of which extensions belong there. Organisation and location fields are taken from the CA's validated records rather than from what you typed. In practice the public key and the names are the parts that carry through.

Common Name is obsolete; the SANs are what matter

For historical reasons the subject's common name looks like the field that names the site, and it has not functioned that way for years. Chrome stopped honouring it in 2017, the other browsers followed, and the CA/Browser Forum requires every name a certificate covers to appear in the subject alternative name extension. A certificate with a CN and no SAN is rejected by every current client regardless of what the CN says.

So the SAN list is the field to read first, and it must contain every hostname the certificate needs to serve - including the bare domain if you serve it as well as the www form. Wildcards cover exactly one label, so *.example.com matches www.example.com and does not match example.com or a.b.example.com.

In a CSR the SANs are easy to miss, and plenty of decoders do. On a finished certificate they are a top-level extension; in a request they are nested inside an extensionRequest attribute, two levels deeper. This tool looks in the right place, so an empty list here means the CSR genuinely lacks them - which is worth fixing before submitting it.

Reading a certificate

Beyond subject and validity, a handful of extensions determine what a certificate is allowed to do, and they are where the interesting answers usually are.

Basic constraints says whether this is a CA certificate. CA:TRUE on a leaf certificate is a serious misissuance; CA:FALSE is what a server certificate should show. Key usage and extended key usage narrow what the key may be used for - serverAuth for a TLS server, clientAuth for mutual TLS - and a certificate missing the usage a client expects will be rejected even though everything else is correct.

Authority information access carries the URL of the issuing certificate, which is how some clients repair an incomplete chain, and the OCSP responder URL. Certificate transparency timestamps show the certificate was logged publicly, which browsers now require. The authority and subject key identifiers are what chain building actually matches on, and are more reliable than comparing issuer and subject strings by eye.

For fingerprints, prefer SHA-256; SHA-1 is shown only because many consoles and pinning configurations still print it. Both are taken over the DER encoding and agree with what openssl reports.

Chain problems

The most common certificate failure is not the certificate. It is the chain: a server that works in a desktop browser and fails in curl, in a mobile app, or in a JVM client.

A server must present its own certificate plus every intermediate up to, but not including, a root. Browsers often paper over a missing intermediate by fetching it from the authority information access URL or by having cached it from another site, so the problem is invisible to the person testing in Chrome and immediate for everything else. Sending the root as well is harmless but pointless - the client already has it or does not trust it.

Order matters in the classical TLS chain: the leaf first, then each issuer in turn. Pasting a full chain here decodes each block separately in the order given, which makes a missing or misplaced intermediate obvious. Match each certificate's issuer against the next one's subject, and check the expiry dates on the intermediates too - they expire as well, and an expired intermediate breaks a perfectly valid leaf.

Generating a request, and the key behind it

A CSR is always produced alongside a key pair, and the key is the part that matters. The conventional command generates both at once: openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr. The -nodes flag leaves the key unencrypted, which is what a web server needs in order to start without a passphrase prompt, and is also why that file must be readable only by the service account.

RSA at 2048 bits remains the safe default for compatibility. ECDSA on the P-256 curve gives equivalent security with much smaller keys and faster handshakes, generated with openssl ecparam -genkey -name prime256v1, and every current browser accepts it. Some older middleboxes and legacy Java clients do not, which is the only real argument left for RSA.

Subject alternative names are the field people forget, because the interactive prompts do not ask for them. They have to be supplied through a config file or the -addext flag, as in -addext "subjectAltName=DNS:example.com,DNS:www.example.com". A request without them will be rejected or, worse, issued with a certificate no browser will accept.

Automated issuance changed the workflow

The manual cycle - generate a CSR, paste it into a vendor portal, wait, download a certificate, install it, repeat next year - is now the exception. The ACME protocol, which Let's Encrypt introduced in 2016, automates the whole exchange: a client proves control of the domain, submits a CSR, and receives a certificate, typically in seconds and with no human involved.

Domain control is proved in one of three ways. HTTP-01 serves a token at a well-known path, which requires port 80 to be reachable. DNS-01 publishes a TXT record, which is the only method that can issue wildcards and the only one that works for a host with no public web server. TLS-ALPN-01 answers a special handshake on port 443, useful where only that port is open.

Certificates issued this way are valid for 90 days by design, on the theory that a short lifetime limits the damage of a leaked key and forces the renewal path to be automated rather than remembered. Clients renew at around two thirds of the lifetime, so a failure has time to be noticed before anything expires.

Validation levels, wildcards and what a certificate proves

Domain validation proves only that whoever requested the certificate controlled the domain at that moment. Organisation and extended validation add checks on the legal entity behind it, which appear in the subject fields of the issued certificate. Browsers stopped giving EV any special interface treatment years ago, so the practical difference today is mostly contractual and procedural rather than something a visitor can see.

A wildcard covers exactly one label: *.example.com matches www and api, but not example.com itself and not a.b.example.com. That is why most wildcard certificates list the bare domain as an additional SAN. Wildcards also concentrate risk, since one key compromise affects every host under the name, and they cannot be issued without DNS control.

None of this says anything about the site being trustworthy. A certificate means the connection is encrypted and the name matches; it has never meant the operator is honest. Phishing sites have valid certificates as a matter of course, which is why browser interfaces stopped implying otherwise.

Expiry is an operational problem, not a certificate problem

Outages caused by expired certificates are common enough to be a genre: they have taken down payment networks, mobile operators and cloud consoles. The certificate did exactly what it was designed to do; what failed was the process around it.

Monitoring should alert on remaining days rather than on failure, with a threshold far enough out to act - two weeks for a 90-day certificate, a month for a one-year one. Monitor the endpoint rather than the file, because the certificate that matters is the one the server is actually presenting, and check intermediates as well: they expire too, and an expired intermediate breaks a perfectly valid leaf.

Certificate transparency logs give you a free inventory. Every publicly trusted certificate is logged, so a search for your domain shows what exists, including certificates someone else in the organisation issued and forgot to tell you about.

Reading a chain when something does not work

The most useful single command is openssl s_client -connect host:443 -servername host, which shows what the server presents rather than what is in your configuration file. The chain it prints should start with the leaf and continue with each issuer in turn, and each certificate's issuer line should match the next certificate's subject line.

A missing intermediate is the classic failure, and it is invisible in a desktop browser because browsers fetch the missing certificate or have it cached from another site. Curl, mobile applications and JVM clients do not, so the symptom is a site that works for the person testing it and fails for a large share of real traffic.

When a chain looks correct and the connection still fails, the next things to check are the key usage extensions, whether the client trusts the root at all, and the clock on the client - a device with the wrong date will reject a perfectly valid certificate as not yet valid.