In this guide
Keys and signatures
Asymmetric cryptography uses a mathematically related public/private key pair. The public key can be distributed; the private key must be protected. Digital signatures use the private key to prove possession and the public key to verify the signature.
In TLS, the private key is normally held by the server or service. The certificate distributes the corresponding public key and describes identities and permitted uses. Losing control of a private key can be more serious than an expired certificate because an attacker may be able to impersonate the service.
X.509 certificates
An X.509 certificate binds a public key to an identity through a CA signature. Important fields and extensions include issuer, subject, serial number, validity, Subject Public Key Info, Subject Alternative Name, Key Usage, Extended Key Usage and Basic Constraints.
SAN, Key Usage and EKU
Subject Alternative Name (SAN) is the important identity extension for modern service certificates. DNS names and IP addresses can be represented there. Key Usage and Extended Key Usage (EKU) constrain intended use, while Basic Constraints identifies CA certificates and can constrain path length.
The Common Name is not a substitute for proper modern SAN validation. A certificate being correctly signed is therefore not enough: the client must also validate the expected hostname or service identity, validity period and appropriate usage.
Trust anchors and chain validation
A trust anchor is configured out of band in a relying party's trust store, normally as a root CA certificate. The client constructs a path from the presented end-entity certificate through intermediate CAs to that trusted anchor.
A typical enterprise hierarchy is offline root CA → issuing/intermediate CA → server or client certificate. Keeping the root offline reduces exposure of its private key and limits the blast radius of an issuing-CA compromise.
Path validation includes signature verification, validity periods, Basic Constraints, Key Usage, policy processing where applicable and certificate-profile rules. Application-specific checks then occur on top, such as TLS hostname validation or 802.1X authentication requirements.
PKI in TLS
During a normal TLS deployment the server presents a certificate chain and proves possession of the corresponding private key. The client validates the chain against its trust store and verifies that the certificate is valid for the destination identity.
For an internal service, this commonly means distributing the enterprise root CA to managed clients. For public services, the certificate is normally issued by a public CA already trusted by the client platform. These are different trust models and should be designed separately.
Revocation
Certificates may need to be invalidated before expiry, particularly after private-key compromise or loss of authorisation.
CRL
A Certificate Revocation List is a CA-signed list of revoked certificate serial numbers. CRLs are useful when cached and downloaded in bulk, but can become large and are not an instantaneous status mechanism.
OCSP
The Online Certificate Status Protocol allows a client to ask for the status of an individual certificate. OCSP stapling allows a TLS server to supply a signed, recent status response with the handshake. Client behaviour when revocation checking fails varies by application and policy, so do not assume a single universal fail-open or fail-closed model.
Enterprise PKI
Microsoft AD CS is a common enterprise implementation. A practical hierarchy is an offline root CA and one or more issuing CAs. Issuing CAs publish CRL and AIA information and issue certificates through controlled templates and enrolment permissions.
Typical consumers include Windows servers, NPS/RADIUS, 802.1X wireless and wired authentication, VPN gateways, web servers, internal APIs and device-management platforms. Automated enrolment is preferable to manually copying certificates.
For internet-facing services, ACME-based automated issuance can remove much of the manual renewal burden. Public and private PKI solve different trust problems and should not be mixed casually.
Operational practice
- Protect CA private keys with strong access controls and HSM protection where risk warrants it.
- Keep a documented CA hierarchy and know which roots are installed on clients.
- Design CRL and AIA publication so clients can actually reach the required locations.
- Control certificate templates, EKUs and who is allowed to enrol.
- Decide whether private keys are exportable and document backup/recovery requirements.
- Plan renewal before expiry and test revocation and recovery procedures.
- Inventory certificate owner, purpose, SANs, issuer and expiry.
- Have a defined process for compromised issuing CAs, compromised keys and emergency trust-store changes.
Troubleshooting certificates
- Check certificate dates and SAN against the identity being accessed.
- Inspect the complete chain actually presented by the service.
- Confirm the root is trusted and intermediate Basic Constraints/Key Usage are valid.
- Check EKU and application-specific requirements.
- Check CRL/OCSP reachability and the client's revocation policy.
- Confirm the private key exists and matches the certificate.
- For 802.1X/NPS, check server certificate, client certificate EKU, trust chain and RADIUS/EAP logs.
Standards and references
- RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
- RFC 6960 — Online Certificate Status Protocol.
- RFC 8446 — TLS 1.3.
- Microsoft AD CS documentation for enterprise certificate services.
Key takeaways
PKI is a trust framework. Keys provide cryptographic identity, certificates carry that identity, CAs provide a trust path, and validation determines whether the identity can actually be trusted for the operation being performed.