Introduction
X.509 certificates bind an identity to a public key. They secure HTTPS, mutual TLS, code signing, document signatures, enterprise authentication and many device identities. When a connection fails, reading the certificate often reveals the cause.
A certificate viewer translates dense ASN.1 structures into issuer, subject, dates, key details, extensions, signatures and fingerprints. The utily.tools X.509 Certificate Viewer performs this inspection from pasted or uploaded certificate data.
A signed statement about a public key
A certificate contains a to-be-signed structure, the signature algorithm and the issuer’s signature. The signed structure includes a serial number, issuer name, validity interval, subject name, subject public-key information and optional extensions.
Trust does not come from the certificate text alone. A client builds a chain from the leaf through intermediate certification authorities to a locally trusted root, validates signatures and constraints, checks time and confirms that the requested identity appears in the appropriate extension.
Technical foundations and behavior
Certificates are encoded with ASN.1 DER. PEM is a textual envelope containing Base64 DER between BEGIN CERTIFICATE markers. Correct parsing operates on DER bytes and maps object identifiers to known algorithms or extension meanings.
Names and SAN
The subject distinguished name may contain common name, organization and location attributes. For TLS hostname verification, the Subject Alternative Name extension is authoritative; modern clients do not rely on common name as a fallback.
Validity and extensions
notBefore and notAfter bound the certificate lifetime. Basic Constraints distinguishes CAs from end entities. Key Usage and Extended Key Usage restrict operations such as signing, key encipherment, server authentication or client authentication.
Fingerprints and signatures
A fingerprint hashes the complete DER certificate bytes, not the Base64 text. It identifies one exact certificate. The certificate signature instead verifies the to-be-signed bytes with the issuer public key and the declared signature algorithm.
Real-world applications
TLS name failure
A certificate may be current and trusted but fail because the requested hostname is absent from the SAN extension.
Unexpected chain
Issuer and Authority Key Identifier fields help distinguish renewed intermediates with similar names during chain debugging.
Certificate pinning checks
Operators compare a SHA-256 certificate or public-key fingerprint through a trusted out-of-band channel.
Standards and deeper technical reference
X.509, PKIX, ASN.1 and DER
X.509 originated in the ITU-T directory standards. For Internet PKI, RFC 5280 profiles X.509 version 3 certificates and version 2 CRLs. The certificate structure is expressed in ASN.1 and normally encoded with DER, a canonical subset of BER. PEM wraps DER bytes in Base64 with BEGIN and END labels.
A certificate contains tbsCertificate, signatureAlgorithm and signatureValue. The issuer signs the exact DER encoding of tbsCertificate; a viewer can decode fields without trusting them, while validation additionally verifies the signature, chain, time and application policy.
| Field | Purpose | Important interpretation |
|---|---|---|
| Serial number | Issuer-assigned positive identifier | Unique per issuer; not globally unique by itself |
| Issuer | Distinguished name of signing CA | Name equality alone does not prove the signing relationship |
| Subject | Identity associated with the public key | May be empty when identity is entirely in SAN |
| Validity | notBefore and notAfter | Necessary but insufficient for trust |
| SubjectPublicKeyInfo | Algorithm and public-key bits | Includes parameters that must be validated |
| Signature | Algorithm and signature over tbsCertificate | Verified with the issuer public key |
Extensions that control real behavior
subjectAltName carries DNS names, IP addresses, email addresses and other identity forms. basicConstraints distinguishes a CA and can limit subordinate path length. keyUsage is a bit field for operations such as digitalSignature, keyEncipherment and keyCertSign. extendedKeyUsage narrows acceptable applications such as TLS server or client authentication.
subjectKeyIdentifier and authorityKeyIdentifier help chain construction but are not trust anchors. certificatePolicies, nameConstraints, CRL distribution points and Authority Information Access affect advanced validation. An unknown critical extension makes the certificate unusable to a conforming validator; an unknown noncritical extension may be ignored.
Reading is not validation
A parser should bound DER length, nesting and collection counts before rendering untrusted fields. Display fingerprints over the original DER bytes and label the hash algorithm. SHA-256 is appropriate for modern identification; an SHA-1 fingerprint may be displayed for compatibility but should not imply SHA-1 signature security.
A decoded certificate can be self-signed, expired, issued by an unknown CA, revoked or valid for another hostname. A viewer should present these as facts and avoid a green trusted state unless it has run a full validation policy with a defined trust store and reference identity.
Primary specifications and references
- RFC 5280: Internet X.509 PKI Certificate and CRL ProfileIETF / RFC Editor
- ITU-T Recommendation X.509International Telecommunication Union
- RFC 7468: Textual Encodings of PKIX StructuresIETF / RFC Editor
Conclusion
An X.509 certificate is a signed, structured binding between identity and public key. Names, constraints, intended usages, dates and the trust chain must be interpreted together.
I believe certificate inspection is an essential debugging skill because many TLS errors become obvious once the right field is visible. Explore your test certificates in the utily.tools X.509 Certificate Viewer and continue with the generation and validation articles.