SSL Certificate & CSR Viewer

Overview

A certificate is a signed set of assertions in DER, a binary encoding, wrapped in Base64 for transport. Everything that goes wrong with certificates in practice is visible in those assertions: a name missing from the SAN list, a validity window that ends sooner than expected, an intermediate pasted where a leaf belongs, a key usage that forbids the use it was bought for.

This viewer decodes the PEM, parses the DER, and lays the contents out — for both X.509 certificates and PKCS#10 certificate requests. It does this in your browser, and it refuses private keys outright.

How to use

1. Paste a PEM block, starting with -----BEGIN CERTIFICATE----- or -----BEGIN CERTIFICATE REQUEST-----.
2. Read the summary: type, subject, issuer, validity, days remaining.
3. Check the SAN list against the hostnames you expect to serve.

To fetch a live certificate from a server: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509

Subject alternative names are the only names that count

The subject Common Name looks like the certificate’s name, and for hostname validation it is not used. Chrome ignored it from version 58, and other browsers followed. Only the subjectAltName extension is consulted.

The practical consequences:

• A certificate whose hostname appears only in the CN fails validation in every current browser, while looking entirely correct in any tool that displays the subject prominently.
• A wildcard *.example.com matches one label. It covers www.example.com and not a.b.example.com, and it does not cover the bare example.com — that name needs its own SAN entry, which is why certificates routinely list both.
• SANs are typed. dNSName, iPAddress, rfc822Name and URI entries are all shown, and a hostname placed in the wrong type does not match.

Reading the key and its usage

The key algorithm and size are read from the public key structure. For RSA the modulus length gives the bit size directly. For EC the named curve is reported where one is used, and where the certificate carries explicit parameters instead of a curve name that is stated as such — explicit parameters are rejected by most modern TLS stacks, so it is worth seeing. If no curve name is present the size is derived from the length of the public point, which is why a P-521 key reports 521 rather than the 528 a naive byte count would give.

keyUsage and extendedKeyUsage describe what the key is permitted to do, and both are enforced. A certificate without serverAuth in its EKU will not work for TLS even if everything else is correct — a common outcome when a client certificate is installed on a server by mistake.

basicConstraints says whether the certificate is a CA. If you pasted what you believed was your leaf certificate and it reports as a CA, you have pasted the intermediate — which is the usual cause of a chain that validates locally and fails elsewhere.

The extension list shows every extension present with its critical flag. A critical extension a client does not understand must cause rejection, per RFC 5280, so an unfamiliar critical extension is worth investigating.

Examples

• A name that will not validate — check the SAN list, not the subject. If the hostname is only in the CN, the certificate must be reissued.
• Reading a CSR before sending it — the CSR fixes the subject and the public key. Confirming the names before submission avoids a reissue cycle, especially where the CA charges for one.
• Confirming which certificate you have — leaf, intermediate and root all look alike as text. basicConstraints and the subject-versus-issuer relationship identify them immediately: a root has an identical subject and issuer.
• Planning renewals — days remaining is shown directly. With the industry moving toward much shorter maximum lifetimes, a manual renewal process that worked for annual certificates does not survive the shift.
• Auditing a bundle — paste each block in turn. A bundle in the wrong order, or with an unrelated certificate included, is a frequent cause of a chain error that appears in some clients only.

Notes

Only CERTIFICATE and CERTIFICATE REQUEST PEM blocks are accepted. Any other block type, including all private key formats, is refused with an error naming what was found. Nothing about a refused block is parsed or shown.

The DER parser rejects what DER forbids: indefinite-length encodings, lengths that run past the end of the buffer, and nesting beyond 32 levels. A truncated paste produces a specific message such as ASN.1 length exceeds buffer rather than a partially filled report, because a half-parsed certificate invites misreading. When parsing fails, any previous result is cleared for the same reason.

Dates are shown as encoded in the certificate. GeneralizedTime carries a four-digit year; UTCTime carries two, and RFC 5280 fixes the interpretation at 50–99 for 19xx and 00–49 for 20xx. Days remaining is computed against your device’s clock, so a wrong system time gives a wrong figure.

This tool reads one certificate in isolation. Chain building, revocation and trust are not evaluated. To see what a server actually sends and how it responds, use HTTP headers and security header checker. Everything here happens in your browser — see the privacy policy.