Inside a Digital Certificate: Fields and How Validation Works

Hi everyone, it's Shii-chan!

Today I found a post about what's actually inside a certificate, and I got really excited reading it!

What was announced?

The JP Windows Support blog published "Contents of a digital certificate and certificate validation". It's the second article in their PKI fundamentals series. The first one covered PKI basics, cryptography, digital signatures, and the role of certificates. This one explains what a certificate contains and how it gets validated.

It's a foundational read rather than a feature launch.

Why it matters

Certificate errors can come from an expired date, a name mismatch, a broken chain, or revocation, and each one needs a different fix. Knowing the contents and the order of checks makes troubleshooting much easier.

The article also notes that validation criteria depend on the application. For example, Microsoft Edge disables online OCSP/CRL revocation checks by default.

What changes

When you open a .cer or .crt file on Windows, you'll be able to read what each field means. That helps infrastructure folks and anyone investigating certificate problems.

Dive Deep

Certificates use the X.509 format, made of basic fields and extensions. The article says X.509 v3 is the common version.

Basic fields

• Version: the format version
• Serial number: identifies a certificate within the issuing CA. Different CAs can reuse numbers, so check it together with the issuer
• Signature algorithm: what the CA used to sign (for example sha256RSA, sha384RSA, sha256ECDSA)
• Issuer: the CA that issued the certificate
• Validity: Not Before and Not After
• Subject: the certificate holder's name
• Public key: the key data, algorithm (RSA, ECC, etc.), and key length

Extensions

• Subject Key Identifier (SKI): identifies the public key, generally a hash of it
• Subject Alternative Name (SAN): alternative names such as DNS names or IP addresses
• CRL Distribution Points (CDP): where the revocation list (CRL) is published
• Authority Key Identifier (AKI): identifies the public key matching the CA private key that signed it; normally equals the issuing CA's SKI
• Extended Key Usage (EKU): the purpose, such as server authentication (1.3.6.1.5.5.7.3.1), client authentication (1.3.6.1.5.5.7.3.2), code signing (1.3.6.1.5.5.7.3.3), or smart card logon (1.3.6.1.4.1.311.20.2.2)
• Key Usage: digital signature, key encipherment, certificate signing, CRL signing, and so on. If EKU is also set, both restrictions must be satisfied
• Authority Information Access (AIA): where the CA certificate and the OCSP responder URL are

The thumbprint isn't stored as a field. It's a hash of the whole certificate's DER data, computed by the OS or tools, and its value depends on the hash algorithm.

Validation steps

• Validity period: is the current time between Not Before and Not After? If not, validation fails
• Subject name: for TLS, the host name you connect to is matched against the SAN
• Trust chain: each signature is verified with the issuing CA's public key, step by step. A root isn't trusted just because it is self-signed; it must already be trusted. Windows starts from the Trusted Root Certification Authorities store, and the root certificate update program automatically adds roots of public CAs that Microsoft has verified
• Revocation: with a CRL, you check that the serial number isn't on the list from the CDP (combined with the base CRL if you use a delta CRL). With OCSP, you ask the responder listed in the AIA

In the article's example, the chain for www.microsoft.com goes through Microsoft TLS G2 RSA CA OCSP 04 and Microsoft TLS RSA Root G2 up to DigiCert Global Root G2 (the root).

Wrap-up

• A certificate is made of X.509 basic fields and extensions
• Trust is decided by combining validity, subject name, trust chain, and revocation checks
• Revocation behavior depends on the application; Edge disables online checks by default

This one is great for Windows operators who want to pin down certificate errors on their own!