What is inside an X.509 certificate
A TLS certificate is a signed statement binding a public key to a set of identities. Structurally it is an ASN.1 SEQUENCE with three parts: the tbsCertificate, which holds everything being attested; the signature algorithm identifier; and the signature value itself. The name tbs stands for to be signed, and it is the portion a certificate authority hashes and signs with its own private key.
Inside the tbsCertificate sit the fields this tool reports. The version is an optional context-tagged integer, and its absence means version 1; a modern certificate is version 3, which is what enables extensions. The serial number is an integer assigned by the issuing CA. The issuer and subject are Name structures, each a sequence of relative distinguished names holding attributes such as CN, O, OU, L, ST and C. Validity is a pair of times, notBefore and notAfter. The subjectPublicKeyInfo carries the algorithm identifier and the key bits.
Version 3 extensions follow, carried in a context-tagged element. The one this tool reads is subjectAltName, OID 2.5.29.17, which is where the hostnames actually live in every modern certificate.
How the decoding works, and how PEM relates to DER
DER is the binary encoding of the certificate: a sequence of tag, length and value triples, where a tag identifies the type, the length may be short form or multi-byte long form, and constructed types contain further triples. PEM is simply that binary base64-encoded, wrapped at 64 characters, and bracketed by BEGIN CERTIFICATE and END CERTIFICATE lines. This tool strips the armour lines and any whitespace, base64-decodes the rest, and then walks the resulting bytes as a real TLV tree rather than scanning for byte patterns.
Several fields need decoding rather than just extraction. Object identifiers are stored in a packed base-128 form, so 1.2.840.113549.1.1.11 arrives as seven bytes and has to be unpacked before it can be recognised as SHA-256 with RSA. Times in UTCTime format carry a two-digit year, which is interpreted with the standard pivot: 50 and above means the 1900s, below 50 means the 2000s. Certificates valid past 2049 use GeneralizedTime with a four-digit year instead, and both are handled.
The serial number is printed as the raw integer bytes in colon-separated hexadecimal, for example 03:e5:93:6f:1a:2c:88:41, which is the same format openssl and browser certificate viewers use. Serial numbers are frequently too large for a JavaScript number, so treating them as a byte string rather than an integer is the only correct approach.
This tool reads a certificate, it does not validate one
This distinction matters and is easy to lose. Decoding tells you what a certificate claims. Validation tells you whether those claims can be trusted. This tool does the first and none of the second. It does not verify the signature on the certificate, so a file whose contents have been altered, or one that was never signed by any real authority, will decode and display exactly like a genuine one.
It also does not build or check a chain. It does not fetch the issuing certificate, does not confirm that the issuer actually signed this certificate, does not check basic constraints or key usage, and does not evaluate whether the root is in any trust store. A self-signed certificate claiming to be issued by a well-known CA will display that CA's name in the issuer field without objection, because the issuer field is just text the certificate carries.
Nor does it check revocation, through either CRL or OCSP, or match the certificate against a hostname. The expiry flag it shows is a pure date comparison between notAfter and your device clock, so a wrong system clock produces a wrong verdict. For a real trust decision use openssl verify, a TLS client library, or a browser, all of which perform the full path validation this tool deliberately does not attempt.
Reading the subject alternative names and the common name
The subject common name was historically where the hostname went, but RFC 2818 deprecated that use and every current browser ignores CN for hostname matching. The authoritative list is the subjectAltName extension, which this tool extracts and displays. It reads dNSName entries, which are context tag 2, and iPAddress entries, which are context tag 7 and are rendered as dotted decimal from their raw bytes.
This is why a certificate can look correct in its subject line and still fail in a browser. If the subject says CN=example.com but the SAN list contains only www.example.com, connections to the apex domain will be rejected. Wildcards are also narrower than people expect: *.example.com matches one label, so it covers www.example.com but not example.com itself and not a.b.example.com.
The algorithm fields are worth a glance too. The signature algorithm tells you how the CA signed, and SHA-1 with RSA in a certificate issued recently is a red flag since browsers stopped accepting SHA-1 signatures years ago. The public key algorithm distinguishes an RSA certificate from an ECDSA or Ed25519 one, which matters when you are matching a certificate to a private key file.