SSL Certificate Decoder

What an SSL certificate decoder shows

An SSL certificate decoder reads an X.509 certificate, the -----BEGIN CERTIFICATE----- block a server sends during the TLS handshake, and prints the fields inside it: who it was issued to, who issued it, when it expires, which hostnames it covers and the public key it carries. It shows what openssl x509 -in cert.pem -text -noout prints, arranged so the parts that break HTTPS stand out.

Most certificate problems are one of four things: the certificate has expired, it does not list the hostname being visited, the server does not send the intermediate certificate, or the private key on the server belongs to a different certificate. The decoder answers the first three directly; the commands it prints answer the fourth.

How it works

A certificate is a DER-encoded ASN.1 structure defined by RFC 5280: the signed part (tbsCertificate), the signature algorithm, and the signature. PEM (RFC 7468) is that DER in base64 between the BEGIN and END lines. The decoder parses the DER itself and refuses malformed input (truncated data, impossible lengths, BER indefinite lengths), saying where it broke.

For a chain, each certificate's issuer name is compared with the next certificate's subject, and the signature is checked with the issuer's public key using the browser's WebCrypto: RSA PKCS#1 v1.5, RSA-PSS, ECDSA on P-256, P-384 and P-521, and Ed25519. Algorithms WebCrypto lacks (DSA, Ed448, secp256k1) are reported as not checked rather than passed. Fingerprints are the SHA-256 and SHA-1 of the DER bytes, identical to openssl x509 -noout -fingerprint -sha256.

The fields that matter

The Common Name in the subject is shown but no longer decides anything: browsers have matched hostnames only against the SAN since 2017 (Chrome 58).

Hostname matching and wildcards

RFC 6125 sets the rules the hostname box follows. A name must equal a DNS entry in the SAN, ignoring case and a trailing dot. A wildcard such as *.example.com covers exactly one label: it matches www.example.com but not example.com and not a.b.example.com, so a certificate for both the apex and its subdomains lists both names. Browsers honour the wildcard only as the whole left-most label and never directly under a public suffix such as *.co.uk. An IP address matches only an IP entry in the SAN.

Chain order

A server should send its certificate first, then each intermediate, each followed by the one that issued it. The root is optional, because clients already hold it. Browsers often repair a broken chain themselves, which hides the problem until curl, a mobile app or a payment webhook fails. With Certbot, point Nginx at fullchain.pem, not cert.pem:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

To see what a server really sends and to check a chain you hold:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pem

Reading a CSR

A certificate signing request (PKCS#10, RFC 2986) carries the subject, the public key and the extensions you are asking for, signed with the matching private key. The decoder shows the requested SANs and checks that self-signature, which proves the request was made by whoever holds the key. A CA issues only what it validates, so check the SANs before you submit. To make a request with SANs in one command (OpenSSL 1.1.1 or later):

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes -keyout key.pem \
  -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -out request.csr

Common errors and how to fix them

• unable to get local issuer certificate (curl error 60, openssl verify error 20): the intermediate is missing. Serve the full chain, then check again with s_client.
• certificate has expired: renew it. If Certbot manages it, sudo certbot renew --dry-run shows why automatic renewal failed (often port 80 blocked, or DNS changed).
• key values mismatch when Nginx starts: the key is not the certificate's. Compare openssl x509 -in cert.pem -noout -pubkey | openssl sha256 with openssl pkey -in key.pem -pubout | openssl sha256.
• no start line from OpenSSL: the file is DER, not PEM, or has something before the BEGIN line. Convert with openssl x509 -inform der -in cert.der -out cert.pem.
• ERR_CERT_COMMON_NAME_INVALID: the name is not in the SAN. Reissue with every hostname the site answers to.

Certificates in Shipown

When you point a domain at an app, Shipown writes the Nginx virtual host, tests the configuration before reloading it, asks Certbot for the certificate and surfaces its expiry; a configuration Nginx rejects is put back the way it was. Server setup offers the Nginx and Certbot install as its own step (server management).