Certificate Lifecycle Management vs Key Management: How They Work Together

We tend to think of the certificate as the thing that secures an HTTPS connection. It is not. A certificate is just a file your server shows to anyone who connects, and anyone can copy it. What nobody else can copy is the private key behind it, and that is the only reason the certificate means anything. Before any traffic flows, your server has to prove it holds that key, and no impostor can produce the same proof.

Certificate management hands your server a certificate and vouches for it, tying it to a name like example.com or an internal hostname. Key management protects the private key that backs it. The two are separate jobs that lean on each other, and they run anywhere your services talk over an encrypted connection, from a public website to two internal services calling each other.

In this guide, you will learn where certificate management and key management overlap and differ. You will see why the key underneath is what everything rests on, where that key should physically be stored, and why shrinking certificate lifetimes force a certificate and its key to rotate as one. And you will see how a single platform, like Infisical, makes that automatic.

Where Certificate and Key Management Overlap and Differ

The short version is that every certificate is built on a key, so the two overlap wherever that key pair is concerned. Certificate management looks after the certificate itself. Key management looks after the key underneath. But key management covers a lot of ground (database encryption, disk encryption, code signing, and API token signing) that has nothing to do with certificates, and certificate management involves work (naming, trust chains, renewal cadences) that has nothing to do with raw keys. They are closely related, but they are not the same thing. Let’s take a closer look into each.

Certificate management

In technical terms, a certificate itself is a signed file, in a standard format called X.509, that binds a public key to an identity such as a domain name. Certificate management is the practice of running certificates through their full life: issuance, renewal, discovery, and revocation, across both public TLS (Transport Layer Security) certificates and the internal certificates that power a private PKI (Public Key Infrastructure).

A Certificate Authority (CA) vouches for that binding by signing it. Trust flows down a chain. A root CA that stays offline signs an intermediate CA, and the intermediate signs the leaf certificate that actually resides on your server. When a client connects, it walks that chain back up to a root it already trusts, and if the path holds, the connection is trusted.

You can also run that chain yourself. Many teams run an internal PKI, a private CA that issues certificates to their own services and devices instead of a public one. These certificates never touch the public web, but they run through the same lifecycle. This is how you get mTLS (mutual transport layer security), where two services each show a certificate and prove they hold the matching key before they talk, and how a new device picks up its certificate as it joins the network.

Once ACME (Automatic Certificate Management Environment) is wired up, renewal runs on a schedule without a human in the loop. ACME is an open standard for automating certificate issuance and renewal between a client and any CA that supports it, public or private. Its most familiar deployment is Let's Encrypt, the free public CA that issues certificates for much of the web, reached through a client like Certbot that a server runs to fetch certificates and renew them before they expire.

Renewing a certificate is easy with automations, but finding them all is not. Certificates get issued outside the normal process, on network appliances, in Kubernetes clusters, and inside application images, and the ones not being tracked are the ones that would expire. Discovery closes that gap by continuously scanning your infrastructure to build a live inventory of every certificate, its issuer, its expiry date, and the service that depends on it.

Key management

Key management is the broader discipline of generating, storing, rotating, and eventually retiring cryptographic keys. Certificates are only one thing keys are used for. An encryption key protects data at rest, like the key that encrypts a customer database so that a stolen disk image reads as nonsense. A signing key proves something is genuine, like the key that signs a release binary so users can tell the build came from you and nobody altered it on the way.

Whatever a key is for, the work around it looks much the same. You generate it from a source of randomness strong enough that nobody can guess the result. You store it somewhere the wrong people cannot read it. You grant access narrowly and log every use, so you know which service used which key and when. You rotate it, replacing it with a fresh key on a schedule (or as soon as you suspect it has been exposed). And once it is retired, you destroy it so that it cannot be recovered later.

For the purposes of certificate key management, the key to focus on is the private key paired with each certificate. It often leaks by accident, committed to a Git repository, copied into a container image, or written out to a build log.

Whoever ends up holding that key can impersonate the service it belongs to. Say it is the key for an internal staging database that mirrors production. An attacker with that key can stand up their own server, present your certificate, and every client that connects will accept the connection as genuine, because the certificate does check out. Your applications keep sending credentials and queries, except now they go to the attacker. Nothing in the logs would look wrong, which is why this can run for a long time before anyone would notice. Key management keeps that from happening, through strong generation, tight access, safe storage, and regular rotation.

Key Storage: HSMs and KMS

Private keys carry a lot of weight, so there are two decisions to make about them: how a key is managed, and what physically holds it. A KMS is what manages the key, and an HSM is one of the places a key can be held.

A KMS (Key Management Service) is the management layer. It generates keys, decides who is allowed to use them, logs every use, and handles rotation. It is where a key's life is governed. A KMS does not hand keys out. You call it to encrypt, decrypt, or sign, and it performs the operation on your behalf.

An HSM (Hardware Security Module) answers the other question, which is what the key material actually resides in. It is a dedicated, tamper-resistant device that generates and holds keys so the raw key never leaves the hardware. The alternative is a software-backed key, held encrypted by the service itself.

So an HSM sits underneath a KMS, and a single KMS can manage keys backed both ways at once, under the same policies and the same audit trail. You might back a CA signing key with an HSM because losing it would be unrecoverable, while the keys for a short-lived test environment stay software-backed in that same KMS. Many teams connect the two over KMIP (Key Management Interoperability Protocol), a standard that lets key stores and tools from different vendors work together.

You see the difference most when you rotate a key. On an on-premises HSM, rotating a key is a planned job. Someone with access runs it on the device, a second person approves it, and the audit log records it. You rotate a root CA key once every few years, and you want every step to be seen and signed off.

Software-backed keys on short-lived infrastructure work differently. A workload starts up, asks the KMS for a key, uses it, and throws it away when the workload shuts down. No person is involved, and rotating the key is just part of a normal deployment.

Pick between them on ease of use as much as on security. Hardware backing gives you the most protection but slows you down, which is worth it for a handful of important keys. Software backing is fast, which is what you want for the thousands of keys that do not need that much care.

Ownership and Operational Differences

Small teams often assign both workflows to one person. As organizations grow, platform and infrastructure teams tend to manage certificates while security and compliance teams handle keys. The larger the organization, and the heavier its regulatory load, the more likely such division becomes. Teams under compliance frameworks like PCI DSS, FedRAMP, or HIPAA generally have to separate duties around keys as a policy requirement. Whether that works comes down to how well the two are coordinated and if done well, you get a system you can audit, automate, and trust from end to end.

The difference is easiest to see in what you actually do. Certificate work is declarative and mostly hands-off. In Kubernetes you define an issuer once, annotate an Ingress with the hostname you want, and cert-manager requests the certificate, drops it into a Secret, and renews it before it expires. Elsewhere it is a Certbot timer or an ACME client built into the load balancer. You touch it when you add a service, and the rest of the time you watch for renewals that failed.

Key work is a request-and-approve loop, and you never handle the key material yourself. You ask the KMS or HSM to sign or decrypt on your behalf. Rotating a key that protects a whole system is a planned change that gets logged, reviewed, and often signed off by a second person. NIST key-management guidance treats it that way, and auditors under PCI DSS or FedRAMP expect such records to exist.

The two meet at the certificate signing request. Before a certificate can exist, you generate a key pair and build a CSR (Certificate Signing Request) that carries the public key and is signed by the private key, which proves you hold it. The CA checks that proof, signs the public key into a certificate, and hands it back. Key management produced the key, certificate management got it vouched for, and every renewal, rotation, and revocation afterward works on that same pair.

How Certificates and Keys Depend on Each Other

The dependency between them is one way, i.e. certificates rest on keys. Plenty of key pairs never touch a certificate, like the ones encrypting a database or signing a release, but no valid certificate can exist without a key pair beneath it. That makes the key the point of failure for everything stacked above it. Recall that a client trusts your certificate by walking down the trust chain, and every link in that chain is a signature made with somebody's private key. If one of those keys gets out, the certificates above it stop being worth much.

A perfectly issued certificate protects nothing if its private key is sitting in a world-readable file or committed to a repository. Attackers actively hunt for keys that leak into repositories, files, and logs, and they find them. A study by Google and GitGuardian traced roughly a million private keys leaked since 2021 to 140,000 certificates, and found 2,622 of those certificates valid as of September 2025. More than 900 of them were protecting Fortune 500 companies, healthcare providers, and government agencies, and only fewer than 100 had been revoked.

There are two ways the trust chain can break:

• The signing key is stolen outright. An attacker who holds it can mint certificates that every client will accept.
• The issuance systems are breached. An attacker never has to touch the key at all, because those systems are the ones that ask it to sign.

The second path is what took down the Dutch CA DigiNotar in 2011. Attackers took over the servers running its certificate authorities and used them to issue 531 fraudulent certificates, including ones for Google domains later used to intercept Iranian Gmail users. Browsers pulled DigiNotar's root from every trust store, and the company was bankrupt within months.

Either path collapses the whole chain built on that CA at once, which is why CA keys, and the systems allowed to invoke them, are guarded so carefully, and why root keys are kept offline.

Structurally the certificate depends on the key, but the trigger tends to run the other way: a renewal is the ordinary reason anyone generates a fresh key pair, and a revocation is the ordinary reason one gets retired early. The key sits underneath, and the certificate sets the clock.

There is no certificate without a key, which means you are already doing key management whether you manage it or not. Strong certificate management with weak key management just hides the risk, and careful key management doesn't help much if certificates are issued and tracked inconsistently. You need both.

Rotating Certificates and Keys in Sync

When a certificate expires or is revoked and a new one is issued, the private key behind it is usually replaced at the same time. Handled that way, the certificate and its key stay aligned where every renewal produces a fresh pair.

What puts this under pressure is that certificate lifetimes keep getting shorter. The CA/Browser Forum has set public TLS certificates on a path down to 47 days by 2029, down from the year-plus lifetimes many teams grew up with. Shorter lifetimes are better for security, because a stolen certificate and key are useful for less time. They also mean rotation happens far more often, and manual rotation does not scale to that cadence.

For example, in 2018 an expired certificate in Ericsson software cut off mobile service for tens of millions of O2 and SoftBank subscribers across the UK and Japan only because the certificate reached its expiry date and nobody had renewed it in time, manually.

Automating rotation solves that problem and introduces a different one. Certificates and keys rotate together only when a single system rotates both. If certificate rotation runs in one tool and key rotation runs in another, the two can fall out of step. A renewal can succeed while the key handling fails, or a key can rotate while the certificate that depends on it does not. The problem would then surface later, when a client rejects the connection. The shorter the certificate lifetime, the more often this can happen.

The case for managing both in one platform

When certificates and keys are managed in two disconnected systems, everyday questions get harder to answer. Auditing takes longer because the data lives in two places, and policy is harder to enforce because no single tool sees everything. Every gap between the tools is another place for mistakes.

Consolidation does not have to mean moving everything into one system. A good setup keeps the control plane (where you manage, automate, and audit) separate from the data plane (where keys physically reside). You can leave your keys in an on-premises HSM you already trust and still run certificate and key management from a single tool that connects to it. You manage everything from one place, and your keys stay where they are.

The Tooling Landscape

Tools in this space fall into three layers. At the top are certificate managers like a Certbot timer or cert-manager. Beneath them sits a key manager, usually a KMS, and under that the storage that holds the keys, an HSM or software.

Many teams run a separate tool at each layer, and that may work fine until the layers have to work with each other. Then everything depends on the integration between them, and when that integration is weak or missing, teams end up writing manual scripts, reconciling state by hand, and finding sync problems the hard way. A tool that covers all three layers removes those seams.

Certificate and Key Management with Infisical

Infisical is built to cover both halves in one place. Infisical Certificate Management runs the full certificate lifecycle covered earlier, with support for ACME, SCEP (Simple Certificate Enrollment Protocol), and EST (Enrollment over Secure Transport) so your existing clients and devices can enroll without manual setup. Infisical KMS manages the keys underneath. Because both are on the same platform, the certificate and the key behind it stay in view together.

To put a certificate on a service, you point an ACME client at Infisical. Copy the ACME directory URL and a pair of EAB (External Account Binding) credentials from your certificate profile, then run one command:

sudo certbot certonly --standalone \
  --server "<acme-directory-url>" \
  --eab-kid "<eab-key-id>" \
  --eab-hmac-key "<eab-secret>" \
  -d api.example.com \
  --email admin@example.com \
  --agree-tos --non-interactive

Certbot generates the key pair on the machine, gets the certificate signed, and writes fullchain.pem and privkey.pem under /etc/letsencrypt/live/api.example.com/. Renewal runs on a timer after that. The private key is now a file on your own server, and it needs to be protected.

A key that you keep in Infisical KMS works the other way around. You create the key once, then call the encrypt API to use it, passing base64 data to the key by its ID:

curl -X POST https://us.infisical.com/api/v1/kms/keys/<key-id>/encrypt \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"plaintext": "<base64-data>"}'

You get ciphertext back, and a matching decrypt call reverses it. The raw key never leaves Infisical, so there is no privkey.pem to commit even by accident. You are now free from securing that file or worrying about it leaking.

Teams with existing investments can point Infisical at a key store they already run. Its PKI and certificate management sit on top of an external KMS or HSM through integrations (KMIP & HSM), so a team that already operates an on-premises HSM does not have to replace it.

That makes it a reasonable fit for teams at very different stages. Teams consolidating a set of siloed tools get one system instead of several. Teams automating for the first time get those enrollment protocols out of the box. Teams that want to get certificate and key management right from the start get both in one system, with the option to add hardware-backed storage as compliance needs grow.

The full set of supported protocols and integrations is documented in the Infisical docs. The relationship between certificates and keys is not going away, and the certificate lifetimes driving all of this rotation are only getting shorter. Managing both together, with clear visibility into how each key and certificate line up, is how you stay ahead of it.