Certificate Management

A digital certificate binds an identity to a public key. A certification authority signs that binding. A relying party can then validate who issued the certificate, when it is valid, what it may be used for, and whether the identity matches the connection.

Certificates appear in public websites, private services, user and device authentication, code signing, email, and document signing. This course focuses on the management skill shared by those uses. You need to know what exists, who owns it, how trust is established, when renewal is due, how deployment works, and what to do when trust must end early.

Certificate management is not the same as cryptographic key management. The certificate is normally public. Its corresponding private key is secret. You manage them together because a valid certificate with an exposed private key is unsafe, while a protected private key with an expired certificate is unusable.

The certificate trust model

Think of a certificate as a signed identity record, not as trust by itself.

A typical chain contains an end-entity certificate, one or more intermediate certification authority certificates, and a root certificate. The relying party starts with a root it already trusts. It validates signatures and constraints from the end-entity certificate toward that trust anchor.

For a TLS server, successful validation also depends on the requested name matching an identity in the certificate. A valid signature for the wrong name does not authenticate the server you intended to reach.

Public trust and private trust solve different problems. Publicly trusted TLS certificates chain to roots distributed by browsers and operating systems. A private public key infrastructure uses trust anchors controlled by one organization. A self-signed certificate can be useful in a tightly controlled trust model, but clients must receive and trust it through a separate secure process.

What a certificate contains

An X.509 certificate contains a serial number, issuer, subject, validity period, subject public key information, a signature, and extensions. Extensions carry most of the rules that matter during operation.

The Subject Alternative Name extension carries identities such as DNS names. Basic Constraints identifies whether a certificate may act as a certification authority. Key Usage and Extended Key Usage restrict how a key may be used. Authority Information Access and CRL Distribution Points can tell relying parties where to find issuer or revocation information.

A certificate signing request carries a public key and requested attributes to an issuer. The issuer still applies its own validation and policy. A request is not a certificate, and signing it is not a clerical step.

The lifecycle you manage

Use one operating loop:

1. Discover and inventory certificates, private keys, trust stores, owners, and dependencies.
2. Define issuance policy, approved issuers, profiles, algorithms, lifetimes, and identity-validation methods.
3. Generate or select a key pair in an appropriate protected boundary.
4. Request and validate the issued certificate and chain.
5. Deploy the certificate, chain, and private-key reference to every intended endpoint.
6. Monitor validity, identity coverage, chain completeness, cryptographic policy, and deployment health.
7. Renew or replace before expiry, with enough overlap to detect failed rollouts.
8. Revoke and replace after compromise or another reason that invalidates the binding.
9. Retire obsolete certificates, keys, trust anchors, and automation permissions.

Inventory is the foundation. A certificate that nobody owns will eventually expire, remain deployed after replacement, or survive beyond the system it protected. Record the issuer, serial number, fingerprint, identities, validity dates, key algorithm, key location, owner, environment, renewal method, deployment targets, and dependencies.

Renewal is replacement

Renewal normally means obtaining a new certificate. The new certificate has its own serial number and validity interval. It may reuse the existing public key or use a new key pair, depending on policy and risk.

Treat renewal as a rollout. Issue early enough to test. Deploy the complete chain. Confirm that every endpoint presents the intended certificate. Keep a controlled overlap when the system needs it. Remove the old certificate and key after rollback risk has passed.

Automation reduces missed renewals, but it also creates a privileged path that can request and deploy credentials. Restrict that path to the identities and systems it needs. Protect account keys and enrollment credentials. Log issuance and deployment. Test failure alerts.

The Automatic Certificate Management Environment, or ACME, standardizes domain validation, issuance, download, renewal, and revocation interactions between a client and a certification authority. ACME automates protocol steps. You still own policy, authorization, private-key protection, deployment scope, and monitoring.

Expiration and revocation solve different problems

Expiration ends acceptance at the certificate's not-after time. It is predictable and should be handled by renewal planning.

Revocation tells relying parties that an unexpired certificate should no longer be trusted. Reasons include private-key compromise, incorrect issuance, or a change that invalidates the certified identity. Certificate revocation lists and the Online Certificate Status Protocol are common status mechanisms.

Revocation is not an instant delete command. Relying parties differ in how and when they check status. Your incident plan should therefore include revocation, replacement, redeployment, private-key containment, and verification across affected clients.

Private keys set the security boundary

Anyone who gains a private key may impersonate the certificate holder or create signatures attributed to it, within the certificate's accepted uses. Prevent export when the platform permits it. Limit access to the process or role that needs the key. Use a hardware-backed or managed key service when the threat model requires stronger isolation.

Do not copy one private key across unrelated systems only because deployment becomes easier. Shared keys enlarge the compromise boundary and make targeted replacement harder. Separate keys let you revoke and replace one affected endpoint without disturbing every peer.

Backups need purpose and policy. Some encryption keys require recovery because losing them can lose data. Authentication signing keys are often better replaced than broadly backed up. Base the decision on the key's function, recovery requirements, and security policy.

Where certificate management fails

Common failures are operational rather than mathematical:

• an unknown certificate expires on a forgotten endpoint;
• the leaf certificate is renewed but one server still presents the old copy;
• the private key and certificate do not form a pair;
• an intermediate certificate is missing or ordered incorrectly;
• the certificate lacks the identity a client actually uses;
• a broad wildcard or shared key expands the impact of compromise;
• automation can request certificates for more identities than intended;
• a compromised certificate is revoked but not replaced everywhere;
• an old private certification authority remains trusted after retirement.

The control is a closed loop. Inventory tells you what should exist. Issuance policy constrains what may exist. Deployment evidence shows what is active. Monitoring finds drift. Renewal and incident procedures change the fleet safely.

When this skill matters

You need certificate management whenever service availability or identity depends on public key infrastructure. It matters to platform engineers operating TLS endpoints, security teams governing issuers and keys, identity teams enrolling users and devices, developers building machine-to-machine authentication, and incident responders containing credential compromise.

You do not need to operate a private certification authority to practice this skill. Most teams should consume a well-governed public or managed private issuer. Running a certification authority adds high-impact key protection, policy, audit, availability, and recovery duties.