A Complete Guide to Certificate Lifecycle Management

Every certificate you have ever issued is a timer counting down to an outage. Many teams cannot say how many certificates they have or where they all live, so the ones nobody knew about expire unnoticed and take production down. Even the renewals you do catch eat hours: chasing down the owner, generating a CSR by hand, getting it signed, and redeploying it without breaking the chain. This video walks through certificate lifecycle management in Infisical at a high level, so you can see how all the pieces fit together.

If you have seen how Infisical handles secrets, this will feel familiar. Certificate Manager applies the same principles to certificates: centralize them, scope access by identity, automate the busy work, and keep everything auditable. That holds across the full life of an X.509, whether you are issuing for TLS, mutual TLS, code signing, or device identity, and whether you sign with your own private CAs or external ones like DigiCert, Let's Encrypt, and Microsoft ADCS. Most importantly, you manage what happens after issuance: renewal, monitoring, deployment, and revocation. That is far better than handing the job to a calendar reminder and good intentions.

The certificates that take you down are usually the ones nobody knew were there, so a natural place to begin is discovery. You give it a set of targets to scan: individual domains, IP addresses, or whole CIDR ranges, plus the ports to check. It reaches out to each one and reports back the certificate being served. You can run it once or on an interval, so it keeps finding new certificates as they show up.

Every place a scan finds a certificate becomes an installation. You are not just seeing the certificates themselves, you are seeing where they actually live. That feeds straight into your inventory.

The inventory is the view many teams have never had: every certificate, where it is, when it expires, and whether it is active, expired, or already revoked. One place to look instead of asking around to figure out what you have. This inventory is the foundation for everything else, because you cannot renew, alert on, or clean up what you are not even aware of.

Before going deeper, here is the high-level picture. The work splits into two groups of people. Platform and security admins set the rules centrally, which is the governance layer. Individual teams then work on top of that, issuing and managing certificates for their own services without ever touching the underlying PKI details.

Underneath, there are five pieces. A certificate authority is the trusted thing that signs. A policy is a set of rules a certificate has to follow. A profile bundles a CA and a policy into a reusable template. An application is a service or workload that attaches a profile and issues certificates through it. And finally there is the certificate that comes out the other end. The first three are the governance layer that security admins own; the application and the certificate are what teams actually work with.

A certificate is only as trustworthy as whatever signed it, so start at the certificate authority. There are two kinds. Internal CAs are a private hierarchy you run inside Infisical, a root with intermediates underneath it, fully managed for you. If you keep your root CA offline and external, which is common for security-conscious teams, you can chain Infisical's intermediates under that root so Infisical handles day-to-day signing while your root stays locked away. When you stand up a CA, you choose root or intermediate, then set the key algorithm, validity, path length, and your CRL distribution points.

The other kind is external CAs, the authorities you already use, connected in: Let's Encrypt and other ACME providers, AWS Private CA, Microsoft ADCS, DigiCert, Venafi, and GoDaddy. Whether a CA is private and operated by you or public and paid for, it lives in the same place and works the same way from there out. Many teams end up with CA sprawl: a public CA for internet-facing certificates, a private one for internal services, maybe another buried in a cloud account, each with its own console. Infisical connects upstream to all of them, so you manage one console instead of five.

Policies are how you stop bad certificates from ever being issued. A policy is a rulebook a certificate has to follow: which domains and subject alternative names are allowed, which key and signature algorithms are acceptable (RSA, ECDSA, and newer post-quantum options), what the certificate may be used for, and the longest it is allowed to live. You do not build all of this from scratch; there are presets for common cases like a TLS server certificate or a TLS client certificate for mTLS, and you tune from there. Each rule can be set to allow, deny, or required.

The team asking for a certificate does not have to be a PKI expert or memorize your naming conventions. The policy is the guardrail. If a request does not comply, it is rejected with a reason instead of quietly becoming a bad certificate, and sensible defaults fill in most of the rest automatically.

A profile is what teams pick up and use. It bundles a few things together: the certificate authority that signs, the policy that sets the rules, and a set of sensible defaults like validity period, key algorithm, and signature algorithm. Put those together and you have defined the shape of a certificate once, so nobody has to reassemble it every time. Because it is reusable, the same policy can sit behind several profiles: maybe one profile points at your internal CA and another at DigiCert, but both inherit the same strict policy. Same rules, different signers.

Everything up to here is set up once and centrally managed. Applications are where the day-to-day work happens. An application represents a service or workload, such as a payments API, a device fleet, or an internal app, and you attach one or more profiles to it. You attach more than one because a single service often needs different kinds of certificates: a payments API might terminate public-facing TLS with a publicly trusted certificate from one profile while authenticating to internal services over mTLS using a client certificate from your internal CA under another.

You also add the team members who work on the application and give each a role, admin, operator, or auditor, depending on whether they configure things, issue certificates, or just look. Inside an application you find its certificates, requests, syncs, and members. This is the team's own workspace, and it is an important boundary: one team's certificates do not bleed into another's, because access is scoped only to the applications you have been added to.

So how does a service actually ask for a certificate? That is what enrollment handles. You turn on an enrollment method for a given profile within your application, and every application-and-profile pairing gets its own dedicated endpoint URL. That endpoint carries two pieces of context at once: which application is asking (the right scope, approvals, and alerts) and which profile to issue under (the right CA and rules). Your tooling just points at one URL and out comes a compliant, renewable certificate. The requester also has to prove who it is to use that endpoint, whether with a machine identity or the enrollment method's own credentials, so not just anyone can ask.

There are four ways to reach that endpoint, depending on what is asking. API for the UI, the agent, or your own scripts. ACME for standard tooling like certbot or cert-manager, the same protocol Let's Encrypt popularized. EST for device and machine identity over mutual TLS. And SCEP, the long-standing option for network gear and MDM-managed device fleets, the protocol behind tools like Jamf and Intune.

Once enrollment is wired up, issuing is the easy part. You request a certificate against a profile, either the CSR way, where your client generates the key pair and sends a signing request, or by letting Infisical generate the key pair and hand it back with the certificate. Either way the request is checked against the profile's policy, signed by the profile's CA, and pulled down in whatever format you need, PEM or a PKCS12 bundle.

Remember that expired certificate from the start? Automated renewal is what keeps it from ever happening. There are two modes. Server-driven renewal has Infisical renew the certificate before it expires and push the new one out, which works when Infisical handles the key material through API enrollment. Client-driven renewal has something on your side, like cert-manager, certbot, or the agent, initiate the renewal itself, which is what you want when private keys must stay on your side and never leave. Either way, you set how many days ahead of expiry it kicks in, and certificates roll over before they lapse without anyone's name on a calendar invite.

Automation handles the routine, but you still want visibility. You can set alerts on the moments that matter: a certificate approaching expiration, being issued, renewed, or revoked. Alerts reach you where your team already works, whether Slack, email, PagerDuty, or a webhook into your own systems. Expiration alerts give you a heads-up window before the date, so even in the rare case a renewal needs a human, you hear about it early and not during a customer outage.

A certificate is not useful until it is on the system that needs it, and you do not want that to be a manual, error-prone step. Certificate syncs handle deployment for you, to AWS Certificate Manager and Elastic Load Balancer, AWS Secrets Manager, Cloudflare custom SSL, Chef, NetScaler, and more. If you are on Kubernetes, cert-manager can issue from Infisical over ACME and store the certificate straight into a Kubernetes secret. When a certificate auto-renews, the sync repushes it automatically, so the new certificate lands exactly where the old one was. There is also the certificate agent, a small daemon you run on your own servers that requests the certificate, writes it to disk where your service expects it, keeps it renewed, and even reloads the service afterward. If you would rather wire things up yourself, you can always download the certificate directly.

Not every machine or user should be able to issue any certificate they want. On top of the role scoping inside an application, you can gate issuance with approvals, so a request for a sensitive certificate sits pending until the right person signs off, the same shape as a pull request review. Because automated systems still need to move fast, a machine identity can be allowed to bypass approval when appropriate, so you are not blocking a deployment pipeline on a human click. Every action lands in the audit log: who requested what, who approved it, when it was issued, when it was revoked.

Sometimes a certificate needs to die before its expiry date because it is compromised, was misused, or the thing it belonged to is gone. That is revocation. You revoke it with a reason, and the authority publishes that through a CRL, the certificate revocation list that clients check to know not to trust it anymore. On the other half of the lifespan, expired certificates do not have to pile up forever; cleanup can age them out automatically.

A couple more things are worth knowing. Certificate Manager also handles code signing, which lives in its own space but follows the same idea: you sign software artifacts with centrally managed keys under the same kind of approval workflow, so an artifact gets signed without the signing key floating around on someone's laptop. And if you are thinking about post-quantum, the newer ML-DSA algorithms are right there in the same algorithm picker as RSA and ECDSA.

That is Infisical Certificate Manager. In one platform you can discover and inventory every certificate you have, issue new ones from private or public authorities, and standardize them with policies and profiles. From there Infisical renews and redeploys them automatically and keeps the whole lifecycle governed with scoped access, approvals, alerting, and a full audit trail. It is the same philosophy behind Infisical secrets management: you should not have to trade security for moving fast. To go deeper on any piece, from Kubernetes and the cert-manager flow to ACME, discovery, and approvals, browse the Infisical PKI docs.