Certificate Lifecycle Management (CLM): the complete guide to surviving short-lived certificates
By CaptainDNS
Published on July 9, 2026
- The arithmetic changes everything: a fleet of 1,000 certificates renewed every 47 days generates more than 7,700 renewals a year, 8 to 9 times the volume of an annual cycle
- Tooling lags behind: according to Keyfactor's PKI report (2024), only 32% of organizations have a certificate lifecycle management tool, while 86% suffered a certificate-related outage within the year
- Six phases, one loop: inventory, issuance, deployment, renewal, revocation, and monitoring, orchestrated by ACME (RFC 8555) and ARI (RFC 9773), form a zero-touch cycle
- To understand why the lifetime drops to 47 days, read the full SC-081v3 reduction timeline; this article is about how to survive it operationally
On July 21, 2024, the Bank of England took down its CHAPS interbank payment system for 91 minutes. No cyberattack, no hardware failure. A single expired TLS certificate on a network component. For an hour and a half, billions of pounds in high-value transactions sat on hold because a file a few kilobytes in size had blown past its date. The lesson is brutal: in modern infrastructure, a forgotten certificate is a ticking time bomb.
The incident is anything but isolated, and the context makes it worse. The CA/Browser Forum has locked in the reduction of the maximum TLS certificate lifetime to 47 days by March 2029, with intermediate phases in 2026 and 2027. The debate is over: short-lived certificates are coming, whether operations teams like it or not. The real question is no longer whether to prepare, but how to keep pace. Renewing a certificate once a year is a calendar chore. Renewing it every 47 days across an entire fleet is production engineering.
This guide is the survival manual. It breaks a certificate's life into six phases, shows how ACME and its ARI extension turn that cycle into a zero-touch loop, walks through an action plan, then broadens out to crypto-agility and post-quantum migration. It targets system administrators, platform engineers, and CISOs who need to build a renewal chain that holds. The why of the regulatory timeline is covered in detail in the article on the 47-day reduction. Here, we talk mechanics.
Check and monitor your certificate expiration
The real problem is no longer the lifetime, it's the volume
The instinctive reaction to 47-day certificates focuses on lifetime: "my certificate only lasts a month and a half now." Wrong analysis. A short certificate is no more fragile than a long one; it encrypts in exactly the same way. The real problem is arithmetic. It comes down to the frequency of operations: what breaks is the multiplication of renewals at fleet scale.
The arithmetic explosion of volume
Do the math on a mid-sized fleet. With annual certificates (398 days), 1,000 certificates mean roughly 1,000 renewals a year, fewer than three a day. That's manageable, even by hand, with a spreadsheet and some discipline.
Switch to 47 days. Each certificate must be renewed about every 30 days (with the safety buffer built into the number 47), roughly 8 times a year. The 1,000 certificates then generate more than 7,700 renewals a year, over 21 operations a day, weekends and holidays included. The multiplier is 8 to 9. No human team keeps up with that pace manually without errors.
One detail compounds the mechanics: domain control validation reuse (DCV reuse) drops to 10 days in the final phase, against 47 days for certificate validity. Two counters, two rhythms. The 47-day validity says how often the certificate must be reissued; the 10-day DCV window says how often your control of the domain must be re-proven. Don't conflate the two: validity is 47 days, proof reuse only 10. As a result, every renewal drags a fresh domain validation behind it, because the previous proof has already expired. The schedule for these phases is covered in the dedicated guide; remember that the validation load multiplies as well.
The real cost of an expiration
Why so much attention over a file that expires? Because an undetected expiration takes the service down, and downtime is expensive. Public incidents remind us often enough.
The Bank of England CHAPS outage of July 21, 2024 (91 minutes of downtime for an interbank settlement system) remains the textbook case of an expired certificate on a critical component. It happened again in December 2025: the bazel.build domain, used by tens of thousands of build pipelines worldwide, became unreachable because its certificate expired, breaking continuous integration chains right down to third parties who had nothing to do with it. And according to Keyfactor's PKI report, 86% of organizations suffered at least one certificate-related outage over the past twelve months. This is not the tail of the distribution. This is the norm.
The cost of these outages is regularly quantified, but beware of shortcuts. Several orders of magnitude circulate, drawn from different methodologies, and merging them into a single figure would be dishonest. Three distinct references are in play:
- Some industry estimates put the cost of a major certificate-related outage between $500K and $5M depending on the criticality of the affected service.
- Keyfactor's PKI report cites an average cost of $2.86M per certificate-related outage for the organizations surveyed.
- Other application-downtime analyses use an order of magnitude of $72K per hour of downtime for a production service.
These figures do not measure the same thing (cost per incident, average reported cost, hourly cost) and come from separate sources. They agree on one point: an expiration is never free, and the price of good tooling is trivial next to it.
Why are only 32% of organizations tooled up?
If the stakes are this clear, why do only 32% of organizations have a certificate lifecycle management tool, according to Keyfactor? Three reasons stack up.
First, the inertia of the annual model. As long as a certificate lasted a year, a calendar reminder and a spreadsheet gave the illusion of control. The automation debt stayed invisible, because forgetting rarely cost anything. Then fragmented ownership: certificates are issued by different teams (network, application, security, contractors), and nobody keeps a complete inventory. And finally, underestimation. Many teams believe they have their fleet under control while they ignore certificates issued at the margins, on a test subdomain or by a cloud service.
The move to 47 days dissolves that illusion. What was one renewal a year becomes unmanageable at eight. Tooling is no longer a comfort. It's a condition of survival.
The 6 phases of the lifecycle
Certificate lifecycle management (CLM) breaks a certificate's life into six phases that run in a loop. Knowing them means spotting where automation must step in and where a failure turns into an outage. These phases are not linear: they form a circle, since the end of one certificate triggers the start of the next.
Phase 1: inventory and discovery
You can't manage what you can't see. The first phase establishes the exhaustive list of certificates in service, and it's harder than it looks. The main threat has a name: shadow certificates.
A shadow certificate is issued outside the official process, often by a team deploying a service to the cloud, a developer testing a feature, or a contractor installing equipment. It appears in no central spreadsheet. It expires without warning. And it's precisely the one that causes the most surprising outages, because nobody was monitoring it.
Discovery relies on several sources, none complete on its own. Certificate Transparency logs publicly record every certificate issued by a public CA for your domains: they say what was issued, but not where it's deployed or whether it's still in service. Active network scanning of your IP ranges and ports fills that gap by observing what's actually presented on the wire, internal certificates included, which are absent from public logs. That leaves the cloud blind spot: querying provider APIs (managed load balancers, CDNs, managed TLS terminations) surfaces certificates that neither CT nor scanning easily sees, because they live inside opaque services. Cross-referencing these three sources is the only way to approach completeness.
The inventory that comes out must record, for each certificate, three non-negotiable pieces of metadata. Its owner, first: the team or person responsible, without whom an alert has nobody to talk to. Its expiration date, which triggers the whole renewal machinery. And its key algorithm, the data point that will make a targeted cryptographic migration possible when the day comes. Without these three fields, the following phases move blind: you can't alert the right person, prioritize urgent renewals, or plan an algorithm switch. An inventory without an owner isn't an inventory. It's a list of suspects.
Phase 2: issuance
Issuance is the moment the CA generates the certificate. It starts from a CSR (Certificate Signing Request), a signed request containing the public key and the domain's identity. The private key never leaves the server. A non-negotiable security invariant.
One too-often-neglected step gates this phase: the CAA record. A CAA-type DNS record declares which certificate authorities are allowed to issue for your domain. If your automation client targets a CA that CAA doesn't authorize, issuance fails silently. Configuring CAA correctly is therefore a prerequisite for any automation that holds; the complete guide to CAA records details the maneuver. And in the era of frequent renewals, a CAA error doesn't break a single renewal: it breaks all future renewals.
Phase 3: deployment
Issuing a certificate is useless if it doesn't reach the server waiting for it. The deployment phase copies the new certificate and its key to the right place, then reloads the service (web server, load balancer, TLS termination) so it takes effect.
This is where a key piece comes in: deploy hooks. A deploy hook is a script run automatically after obtaining a new certificate. The critical point isn't the reload, it's the validation before the reload. A good hook verifies that the new certificate is valid, that its chain is complete, and that the private key actually matches the public key, before touching the production service. Reloading with a corrupted certificate or an incomplete chain turns a routine operation into an outage. The rule is simple: validate, then reload, never the reverse.
That detail separates automation that holds from automation that lulls you into a false sense of security. A renewal can succeed on the CA side (the certificate is duly issued) and fail on the deployment side (the file isn't copied, the reload crashes, the intermediate chain is missing). Without post-deployment validation, these failures stay invisible until a visitor hits a certificate error. A well-designed hook goes further than a simple check: it opens a real TLS connection to the service after reload, confirms that the served certificate is indeed the new one, and in case of anomaly, keeps the old valid configuration rather than switching to a broken one. This is atomic deployment applied to certificates: you only go to production if the new version is proven functional, otherwise you prefer a still-valid certificate over an outage.
Phase 4: renewal
Renewal reissues the certificate before it expires. It's the most sensitive phase: its failure leads straight to an outage. Contrary to popular belief, a renewal is not an extension. It's a full reissuance, with a fresh domain validation if the DCV window has expired.
The whole strategy comes down to the renewal window, meaning the moment you trigger the operation before expiration. Too early, you waste lifetime. Too late, you have no margin left if something goes wrong. The 47 days were calibrated precisely to leave a comfortable buffer if you renew about thirty days before the deadline: that leaves roughly fifteen days to detect and fix a failure before the outage. But that buffer only holds if renewal is attempted early enough and if you catch the failure while it's still running. Hence the decisive role of monitoring.
Classic mistake: treating a renewal failure as a rare event, handled case by case. At one renewal a year, that worked. At eight renewals a year per certificate, across an entire fleet, failures become statistically certain. A momentarily unavailable DNS provider, a CAA record changed by mistake, an API quota reached, a forgotten credential rotation: each of these mundane incidents blocks a renewal. So the question isn't whether a renewal will fail, but how many will fail each month, and whether your chain catches them on its own (scheduled retry) and flags them in time. A mature pipeline treats failure as a nominal case, not an exception.
Phase 5: revocation
Revocation invalidates a certificate before its natural expiration, for example after a private key theft. Historically, it relies on two mechanisms: revocation lists (CRL) and the OCSP protocol. Except both are largely broken in practice (CRLs too bulky, OCSP in soft-fail that browsers ignore), a point developed in the guide on lifetime reduction.
The good news is that short-lived certificates make revocation less critical. A compromised 47-day certificate expires on its own within a few weeks, which bounds the exploitation window without depending on a broken revocation mechanism. Revocation remains useful for serious compromises, but it's no longer the only line of defense. The short lifetime already does part of the work.
Phase 6: monitoring
Monitoring is the safety net that catches the failures of the other five phases before they turn into an outage. It alerts as expiration approaches, typically at 60, 30, 15, and 7 days before the deadline, with escalation that ramps up as the date nears.
One principle matters more than the rest here: monitoring must be independent of the automation client. If the system that renews your certificates is also the one that alerts you to their expiration, its failure deprives you of the renewal and the alert, at the worst possible moment. The vantage point must therefore be external, observing the certificate actually served on the network rather than the internal state of the renewal. That's the difference between "my client thinks it renewed" and "the world sees a valid certificate."
This independence is no theoretical refinement: it targets the sneakiest class of failures. The certificate was duly issued, the automation client shows "success," the internal logs are green, but the file didn't land on the right server, or an old cluster node still serves the previous certificate, or an intermediate TLS termination wasn't reloaded. All of this stays invisible from inside the renewal system. Only an external probe, one that opens a real TLS connection from the Internet and reads the expiration date of the certificate actually presented, sees it. Last-resort monitoring doesn't trust what the renewal declares: it verifies what the service serves. Same logic that separates a unit test from an end-to-end test, applied to certificates.
ACME automation: from manual to zero-touch
The six phases only hold at high frequency if they're automated. The protocol that makes this possible is called ACME. Its ARI extension makes it smooth and predictable. Together, they turn a manual cycle into a zero-touch loop, where renewal happens without any human hand intervening.
The ACME protocol (RFC 8555)
ACME (Automatic Certificate Management Environment), standardized in RFC 8555, describes the automated dialogue between a client (your server) and a certificate authority. Three steps: the client proves it controls the domain, the CA verifies the proof, then issues the certificate.
One subtlety is worth pausing on: ACME has no notion of "renewal." No "renew" endpoint. A renewal, in ACME, is just a new issuance, identical to the first. The absence is deliberate: it guarantees that every certificate comes out of a fresh validation, with no persistent state that could drift. This design also explains why shrinking the DCV window weighs so heavily. Since every renewal is a fresh issuance, it triggers a new validation as soon as the previous proof has expired. No shortcut.
Proof of domain control goes through two main challenges. With DNS-01, the client publishes a TXT record under _acme-challenge.captaindns.com containing a value derived from a token supplied by the CA; the CA then queries DNS to confirm its presence. It's the only challenge compatible with wildcard certificates (*.captaindns.com), and it works even when the target server isn't exposed to the Internet, which makes it ideal for automated environments and internal infrastructure. With HTTP-01, the client places a file at a specific URL (/.well-known/acme-challenge/) that the CA fetches over HTTP; easier to set up on an already-exposed web server, but it doesn't handle wildcards and assumes port 80 is reachable from outside. The choice depends on your topology, but DNS-01 wins out as soon as there are wildcards, environments with no exposed web server, or a desire to decouple issuance from service availability. In every case, automating the challenge assumes your DNS provider exposes an API. Without one, DNS-01 becomes manual again, hence unusable at high frequency.
The ARI extension (RFC 9773)
ACME automates issuance, but it leaves one question open: when to renew? The naive answer ("30 days before expiration") doesn't scale. If every client of a CA renews at the same threshold, the CA takes load spikes, and an emergency revocation on its side can't be signaled to clients.
ARI (ACME Renewal Information), standardized in RFC 9773, solves this. The CA now exposes, for each certificate, a suggested renewal window that the client polls regularly via a dedicated endpoint. Instead of hardcoding "renew 30 days before expiration," the client asks the CA "when should I renew this specific certificate?" and follows the answer. Three benefits.
Smoothing, first. The CA spreads suggested windows over time to avoid waves of simultaneous renewals. Without ARI, millions of certificates issued the same day would tend to renew the same day, concentrating load; with ARI, the CA staggers them over several days, benefiting its own infrastructure as well as the stability of the ecosystem. Responsiveness, next. If the CA has to revoke a batch of certificates en masse (for example after a compliance incident forcing it to reissue everything), it moves the suggested window forward, and clients that respect ARI renew before the revocation, with no downtime. An emergency channel from the CA to its clients, where a mass revocation used to cause cascading outages. The third benefit comes down to throughput: ARI-guided renewals generally escape the CA's rate limits, which becomes essential at high frequency. A client that renews eight times a year per certificate, across thousands of certificates, would quickly saturate standard quotas. ARI thus turns renewal from a unilateral client decision into a continuous negotiation with the CA. Practical upshot: requiring ARI support is one of the sharpest criteria when choosing a client or platform.
Choosing your client: scripts or platform?
The protocol is standardized, so the choice comes down to the client that implements it. For a single server, certbot renew (the EFF's reference client) launched by a scheduled task is enough: it checks the deadline, renews as needed, and triggers the configured deploy hooks. acme.sh, a dependency-free shell script, offers comparable flexibility and supports dozens of DNS APIs for the DNS-01 challenge.
The real dividing line separates the script approach from the platform approach. Scripts (certbot, acme.sh, a server with native ACME like some reverse proxies) suit a handful of well-controlled servers: zero entry cost, but inventory, cross-cutting monitoring, and governance stay on your shoulders. A CLM platform centralizes these functions across hundreds or thousands of heterogeneous certificates: automatic discovery, expiration dashboard, issuance policies, CAA control. The switch trigger isn't the certificate count alone, it's the heterogeneity of the fleet and the need for centralized governance.
The Let's Encrypt case: the short-lifetime scout
For ten years, Let's Encrypt has played the role of a real-world laboratory for short-lived certificates. The authority announced on December 2, 2025 the move of its default lifetime from 90 days to 45 days, anticipating the regulatory timeline to give the ecosystem time to validate its pipelines. It already offers short-lived certificates of 6 days for fully automated environments (CDNs, cloud platforms): proof that a sub-7-day lifetime holds at industrial scale. And since January 15, 2026, it even issues certificates for IP addresses, in general availability. The message never changes: what looks extreme today becomes the norm tomorrow, and already-automated infrastructure will experience the transition as a non-event.
🎯 Action plan: your CLM checklist
The theory is laid out. Here's the sequence for building a renewal chain that holds. Each step prepares the next; don't reorder them.
- Discover: run a multi-source discovery (Certificate Transparency logs, network scanning, cloud APIs) to flush out shadow certificates. Assume your mental inventory is incomplete until proven otherwise.
- Inventory: record for each certificate its owner, its expiration date, and its key algorithm. These three pieces of metadata carry everything else.
- Deploy an ACME client with ARI: choose certbot, acme.sh, or a CLM platform depending on fleet heterogeneity, and verify that ARI support is active so you benefit from smoothing and the rate-limit exemption.
- Validate DNS: configure the CAA record to authorize your CA, and give the client the DNS API access needed for the DNS-01 challenge, with minimal permissions limited to
_acme-challengerecords. - Wire up deploy hooks: automate post-issuance deployment with systematic validation (complete chain, key match) before reloading the service.
- Monitor in a staggered and independent way: set alerts at 60, 30, 15, and 7 days, from an external vantage point distinct from your automation client.
- Test in
--dry-run: verify that renewal runs without a human hand before relying on it in production. An untested pipeline is a pipeline that will fail at the worst moment. - Document emergency revocation: write the immediate revocation procedure for a key theft, even if short lifetimes reduce its criticality. A procedure written in calm beats improvisation in a crisis.
Manual vs automated: the impact of volume
At a constant fleet of 1,000 certificates, moving from 398 to 47 days multiplies the operational load. Automation is no longer a comfort but a condition of holding.
Annual renewals at 398 days
About 3 operations a day, sustainable manually with discipline.
Annual renewals at 47 days
More than 21 daily operations, weekends included, beyond human reach.
Load multiplier
The volume of operations is multiplied by 8 to 9 at constant fleet size.
Organizations tooled up with CLM
Per Keyfactor's PKI report, two thirds of organizations remain without a dedicated tool.
Crypto-agility and post-quantum migration
CLM isn't just about expiration. By building a reliable renewal chain, you gain a capability whose value goes far beyond preventing outages: crypto-agility. It's the hidden benefit of the 47-day constraint.
A three-pillar model
Crypto-agility is an organization's ability to change cryptographic algorithm fast and without breakage. It rests on three pillars, which map exactly onto the functions of CLM. Discovery: knowing where all your certificates are and which algorithms they use (the inventory phase). Governance: having issuance policies and centralized control of who issues what (the role of a CLM platform). Automation: being able to reissue the entire fleet without a human hand (the ACME loop). An organization that holds these three pillars can pivot its cryptography. One that doesn't is a prisoner of its algorithms.
Why does 47 days drive crypto-agility?
The short lifetime is forced training. A team that renews its certificates eight times a year, in an automated and reliable way, has built up its rotation into a production reflex. That muscle is exactly what it takes to change algorithm. Conversely, a team that renews once a year, by hand, painfully, will be unable to migrate its fleet in an emergency when the day comes. The 47-day regulatory constraint therefore produces an unintended effect: it makes organizations agile in spite of themselves. The chore becomes an asset.
Post-quantum in the crosshairs
That rotation muscle will soon be put to use. In 2024, NIST published the final post-quantum cryptography standards, notably ML-KEM (key exchange) and ML-DSA (digital signatures), designed to resist future quantum computers. Systems are starting to integrate them: Windows Server 2025 introduced support for post-quantum algorithms in November 2025. The switch to these algorithms will require reissuing every existing certificate, perhaps within a tight window.
But you can't migrate a fleet you can't see and renew by hand. CLM is the prerequisite for post-quantum migration: without a complete inventory, without governance, and without automation, a cryptographic migration at scale is impossible. We won't unpack the post-quantum transition here, a vast subject in its own right. Just note the link: building a reliable CLM chain today equips you with the one tool that will make that transition manageable tomorrow.
FAQ
What is certificate lifecycle management (CLM)?
CLM (Certificate Lifecycle Management) is the set of processes governing the life of a TLS certificate, from its discovery to its revocation. It covers six phases: inventory, issuance, deployment, renewal, revocation, and monitoring. Its goal is to prevent expiration-related outages and ensure that every certificate in service is valid, up to date, and known.
What are the six phases of a certificate lifecycle?
The six phases are: inventory and discovery (listing every certificate, including shadow ones), issuance (generation via a CSR), deployment (copying to servers and reloading), renewal (reissuance before expiration), revocation (invalidation in case of compromise), and monitoring (expiration alerts). They form a continuous loop rather than a linear sequence.
How do you automate certificate renewal?
Automation relies on the ACME protocol (RFC 8555), implemented by clients like certbot or acme.sh. The client proves domain control via a DNS-01 or HTTP-01 challenge, the CA verifies, then issues the certificate. The ARI extension (RFC 9773) adds a CA-suggested renewal window. Deploy hooks then deploy the certificate with no human intervention.
How do you monitor certificate expiration?
Effective monitoring staggers alerts at 60, 30, 15, and 7 days before the deadline, with increasing escalation. The point that changes everything: it must be independent of the automation client and observe the certificate actually served on the network, not the internal state of the renewal. A renewal failure is thus detected even when the renewal system itself is down.
What is a shadow certificate or shadow IT?
A shadow certificate is a certificate issued outside the official process, often by a cloud team, a developer, or a contractor, without being recorded in the central inventory. These certificates expire without warning and cause surprising outages, because nobody monitors them. Discovering them goes through Certificate Transparency logs, network scanning, and cloud provider APIs.
What is the difference between ACME and ARI?
ACME (RFC 8555) is the protocol that automates certificate issuance: proof of domain control, verification, issuance. ARI (ACME Renewal Information, RFC 9773) is an extension that answers the question of when to renew: the CA exposes a suggested window, which smooths load, enables anticipated emergency revocations, and generally exempts renewals from rate limits.
What is the lifetime of a TLS certificate in 2026?
In 2026, the maximum lifetime of a public TLS certificate drops to 200 days (first phase), before 100 days in 2027 then 47 days in 2029, per the CA/Browser Forum's SC-081v3 ballot. The full timeline and the reasons for this reduction are detailed in our guide on the 47-day reduction.
Do you need a CLM platform or are scripts enough?
Scripts (certbot, acme.sh) are enough for a handful of well-controlled servers: zero cost, but inventory and governance are on you. A CLM platform becomes necessary as soon as the fleet is heterogeneous, spread across several teams, and requires centralized governance (automatic discovery, issuance policies, dashboard). The switch criterion is heterogeneity and the need for control, not the certificate count alone.
What is crypto-agility and why does it matter?
Crypto-agility is the ability to change cryptographic algorithm quickly and without breakage. It rests on three pillars that map onto CLM: discovery, governance, and automation. An organization that renews its certificates reliably has built up its rotation process, which prepares it for future migrations, notably toward post-quantum cryptography standardized by NIST.
How much does a certificate-related outage cost?
Several estimates circulate, drawn from distinct methodologies that should not be merged: a range of $500K to $5M per major outage depending on service criticality, an average cost of $2.86M per reported outage in Keyfactor's PKI report, and an order of magnitude of $72K per hour of application downtime. They converge on one point: an expiration is never free.
Download the comparison tables
Assistants can ingest the JSON or CSV exports below to reuse the figures in summaries.
📖 Glossary
- CLM (Certificate Lifecycle Management): the set of processes covering the six phases of a TLS certificate's life, from discovery to revocation, whose goal is to prevent expiration outages and keep a fleet under control.
- ACME (Automatic Certificate Management Environment): a standardized protocol (RFC 8555) automating the dialogue between a client and a certificate authority for the issuance and renewal of certificates. It has no notion of renewal: every renewal is a new issuance.
- ARI (ACME Renewal Information): an ACME extension (RFC 9773) through which the CA communicates a suggested renewal window to the client, enabling load smoothing, anticipated emergency revocations, and rate-limit exemption.
- DCV (Domain Control Validation): the process by which a CA verifies that the applicant controls the domain. DCV proof reuse is capped at 10 days in the final phase of SC-081v3, imposing near-continuous revalidation.
- CSR (Certificate Signing Request): a signed request containing the public key and the domain's identity, sent to the CA to obtain a certificate. The associated private key never leaves the server.
- Revocation, CRL, and OCSP: mechanisms meant to invalidate a certificate before its expiration. CRLs (revocation lists) are too bulky and OCSP suffers from the soft-fail that browsers ignore, making revocation unreliable; short-lived certificates reduce its criticality.
- Crypto-agility: an organization's ability to migrate quickly to new cryptographic algorithms, resting on the three pillars of discovery, governance, and automation, all covered by CLM.
- Short-lived certificate: a certificate with a very short lifetime (6 days at Let's Encrypt), meant for fully automated environments and demonstrating the industrial viability of ultra-short lifetimes.
An up-to-date inventory and an automated renewal chain are only worth as much as the DNS layer that underpins them. Since domain validation now depends on the DNS chain of trust, verify that your DNSSEC is valid and consistent with our DNSSEC diagnostic tool: a broken chain silently blocks every renewal.
📚 Related certificate and DNS guides
- SC-081v3: 47-day TLS certificates, why it matters and how to prepare: the regulatory timeline and the why of the lifetime reduction.
- DANE and TLSA: the complete guide: authenticate your certificates via DNS and manage TLSA rotation at the pace of renewals.
- CAA records: the complete guide: lock down the authorities allowed to issue for your domain, a prerequisite for reliable automation.
Sources
- RFC 8555: Automatic Certificate Management Environment (ACME)
- RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension
- Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days
- Ballot SC-081v3: Reduce Validity and Data Reuse Periods (CA/Browser Forum)
- Keyfactor: State of Machine Identity Management (PKI Report 2024)
