TLS certificates now live 200 days. In 2029 it will be 47. Manual processes will not survive this.

In April 2025, the CA/Browser Forum passed ballot SC-081v3: “Introduce Schedule of Reducing Validity and Data Reuse Periods” (voting record), proposed by Apple and endorsed by Google Chrome, Mozilla and Sectigo. The ballot sets a fixed schedule for the maximum lifetime of publicly trusted TLS certificates — and for how long domain validation data may be reused:

The first step is already behind us. We are now in the 200-day era, and the next cut is seven months away.

The arithmetic nobody can escape

Renewal frequency per certificate follows directly from the table:

• 398 days → roughly 1× per year
• 200 days → roughly 2× per year
• 100 days → roughly 4× per year
• 47 days → roughly 8× per year

By 2029, domain validation data can be reused for only ten days. Re-validating a domain effectively becomes part of every single issuance.

Take an estate of 500 certificates — a modest number for a mid-size enterprise. At 47 days, that is on the order of 4,000 issuance events per year, or about 16 per working day, each needing validation, signing, distribution and deployment. No ticket queue, spreadsheet or calendar reminder survives that. The question is no longer whether to automate certificate lifecycle management, but what your automation covers — and what it leaves out.

The two patterns we keep seeing

In enterprise environments we repeatedly encounter the same two coping strategies:

1. The long manual process. A certificate request becomes a ticket, waits for a PKI team, gets signed by an internal CA after days or weeks, and is installed by hand. At 398-day lifetimes this is merely slow. At 200 days it hurts. At 47 days it is an outage generator.
2. Shadow-IT Let’s Encrypt. Teams route around the bottleneck and fetch free certificates directly — outside inventory, outside policy, sometimes outside any record at all. Nobody knows what exists, where it is deployed, or when it expires. Compliance becomes archaeology.

Both are symptoms of the same gap: there is no single control point that knows all domains, all certificates and all signing paths — and that can act on them.

One control point, per-domain dispatch

This is the problem our Rescile Enterprise Certificate Manager addresses. It is a module based on the rescile controller, available as stand-alone or as part of the Souverign UCS. The design is deliberately simple: instead of forcing every certificate through one workflow, it maintains a graph of your PKI — CAs, HSMs, domains, certificates, systems, teams — and dispatches per domain to the signing mechanism that fits.

Domains are plain configuration (CSV, Git-diffable):

name,owner,validation_method,dns_provider,provider,signing_action
internal.corp,team-alpha,dns-01,aws-route53,internal-pki,openssl
corp,team-alpha,dns-01,aws-route53,digicert,cfssl
example.com,team-bravo,dns-01,aws-route53,letsencrypt,acme_dns01

Four dispatch patterns cover what we find in practice:

1. Upstream ACME service. For public domains, the certificate manager terminates ACME itself (RFC 8555) and routes the request onward — e.g. to Let’s Encrypt with DNS-01 validation through your DNS provider. Your internal clients (certbot, acme.sh, Traefik, …) talk to one ACME endpoint, not to the internet directly. Domains that are not under management are rejected with rejectedIdentifier — so shadow issuance through the corporate path simply does not happen.

2. Internal Linux-based CA. For internal domains, orders are dispatched to an internal issuing CA — OpenSSL- or CFSSL-based — driven from the same inventory. Short-lived internal certificates stop being a special case.

3. Internal PKI on Windows AD CS or an offline CA. Many enterprises run Active Directory Certificate Services, or keep an issuing CA deliberately offline. For these domains the certificate manager prepares a signing bundle (CSR and metadata) that an operator downloads, signs with the existing PKI tooling — certreq on AD CS, an air-gapped Linux CA, an HSM-backed ceremony — and uploads back. The audit trail stays in one place even where the key never touches the network.

4. Manual raising. Not everything should be fully automatic from day one. An engineer can raise a certificate request directly from the dashboard; it flows through the same inventory, policy checks and dispatch rules as any ACME order.

Certificate inventory: status, validity, issuing CA, ACME order traceability and per-certificate actions (Sign / Rekey / Revoke) in one view.

Governance that runs continuously, not at audit time

Because every certificate, CA and key lives in one graph, policy stops being a document and becomes code that is evaluated on every change:

• maximum validity per environment (e.g. 90 days in production),
• minimum key strength (RSA ≥ 3072, ECC ≥ P-384), deprecated algorithm detection,
• air-gapped root CA enforcement; CA keys on FIPS 140-2/3 Level 3 HSMs,
• expiry alerting and orphaned-certificate detection.

Violations are visible the moment they appear — not after the next manual inventory:

Compliance rules are evaluated continuously against the live inventory. The 90-day maximum validity rule shown here is exactly the discipline SC-081v3 will force on everyone.

The full trust topology — roots, intermediates, providers, HSMs, active certificates — is derived from the same data:

And the certificates you don’t know about yet

Automation handles the managed estate. The harder question is what cryptography exists outside it. A companion crypto-inventory module builds a crypto asset inventory (a CBOM in the CycloneDX sense): which applications and endpoints use which protocols and algorithms, anchored to a public algorithm registry, so that questions like “where do we still rely on RSA-2048?” — or later, “where do we need post-quantum migration?” — have a data-driven answer.

Built to be inspected

The certificate manager runs on rescile, a graph-based infrastructure platform. Inventory is CSV, models and policies are TOML, templates are Tera. Everything is text, everything is versionable, and there is no black box between your data and the dashboard. If your auditors ask why a certificate was issued, the answer is a Git history, not a support ticket.

The screenshots in this post are from the reference deployment: CA management and air-gapped roots, HSM inventory with FIPS levels, and the issuing path end to end.

Getting ahead of the schedule

As of writing, 15 March 2027 is seven months away. The sensible order of operations:

1. Inventory first. You cannot automate what you cannot see — including the shadow-IT certificates.
2. Automate the simple majority. Public domains via ACME, internal domains via an internal CA.
3. Bring the exceptions into the same system. AD CS and offline CAs via the bundle workflow, so the audit trail is complete.

We are happy to walk you through the reference setup — or you can start by pointing one domain at it and watching the first order go through.

Rescile Enterprise Certificate Manager — graph-based PKI and certificate lifecycle management: inventory, per-domain ACME dispatch, internal and air-gapped CA integration, continuous compliance. rescile.com