Millions of US federal employees and contractors carry a PIV (Personal Identity Verification) smart card mandated by HSPD-12 and standardized in FIPS 201. Each card holds X.509 certificates that chain up to the Federal Common Policy CA — a completely separate root of trust from the one your browser uses for the public web, built for badge readers and government systems rather than websites.
What fields make up a certificate
- Subject — who the certificate was issued to (a domain, organization, or in PIV's case, a federal employee).
- Issuer — who issued the certificate (a certificate authority, or CA).
- Validity period — the start and end dates the certificate is valid.
- Public key — the key used to establish a secure connection or verify a signature.
- Digital signature — the issuer's signature, confirming the authenticity of all the other fields.
Same format, parallel trust worlds
A PIV certificate and a website's TLS certificate share the exact same X.509 structure and the same chain-of-trust mechanics — an intermediate CA signs the end certificate, and a root CA signs the intermediate. The only difference is which root store checks it: your OS keychain trusts the Federal Common Policy CA for smart-card logins, while your browser trusts an entirely different set of roots (DigiCert, Let's Encrypt, and others) for HTTPS — the two chains never need to meet.
Why the validity period is limited
A limited validity period (usually 90 days to 1 year for modern web certificates, longer for PIV cards) reduces the risk from a compromised private key and forces cryptographic parameters to be regularly updated in line with current security standards.
Why you'd need this
- Diagnosing SSL certificate issues when configuring a web server.
- Checking a certificate's validity period and issuer without relying on external services.
- Understanding certificate structure when working with mTLS, client certificates, or smart-card-based authentication.
Self-signed certificates
A certificate can be signed with its own private key instead of any CA at all — structurally it looks identical to a "real" X.509 certificate, with the same fields, except its Issuer and Subject match. This is the same trust question taken to its logical extreme: the chain leads nowhere, so nothing outside your own configuration has a reason to trust it, which is exactly why it's fine for internal testing but flagged everywhere else.