TLS Certificates and PKI Lifecycle: Automation Before the 47‑Day Era

What is changing and why it matters

Every time a browser shows a padlock, a chain of trust is being checked: the site presents a certificate, signed by an intermediate authority, signed in turn by a root that the browser or operating system already trusts. The certificate has a start and an end date. The rules that public certificate authorities must follow, the Baseline Requirements, are written by the CA/Browser Forum, a group of certificate authorities and browser vendors. Those rules also cap how long a certificate may be valid. For years that cap was 398 days, which is why many teams renew once a year, often by calendar reminder and a ticket.

The ballot known as SC-081 changes that. The Baseline Requirements now carry a table of relevant dates. From 2026-03-15 the maximum validity of subscriber certificates is 200 days. From 2027-03-15 it is 100 days. From 2029-03-15 it is 47 days. The same table cuts how long a certificate authority may reuse an earlier domain validation: 200 days from 2026-03-15, 100 days from 2027-03-15 and 10 days from 2029-03-15. Reuse of validated subject identity information, which matters for organization-validated certificates, is 398 days from 2026-03-15. We read these dates in the current Baseline Requirements text; secondary sources describing the April 2025 ballot agree with them.

Two practical consequences follow. First, a certificate bought today for a full year will be impossible to buy in 2027, and by 2029 an administrator who renews manually would be doing it about every six weeks per name. Second, the shorter reuse of domain validation means the certificate authority has to re-check that you control a domain far more often. A process that depends on someone clicking an approval email stops being workable. The rule is not a law; it is a condition the browsers place on the authorities they trust. In practice that is just as binding for any site that wants a public certificate.

Why shorter lifetimes are a security improvement

A certificate is a signed claim that a key belongs to a name. If the key is stolen, or the certificate was issued to the wrong party, the claim stays believable until it expires or is revoked. Revocation has always been weak in practice: checking it adds delay and failure modes, and many clients fall back to accepting a certificate when the check fails. Short lifetimes work around that weakness. If a certificate lives for 47 days, the longest an attacker can use a stolen one is 47 days even if nobody ever revokes it. Short lifetimes also limit how long outdated domain ownership claims persist: a domain that changed hands is not still vouched for by a validation from a year ago.

There is also an agility argument. Cryptographic algorithms are retired over time, and the move to post-quantum algorithms will require reissuing certificates in volume. An organization that can reissue everything in a day because it already does so every few weeks is better placed than one that discovers its certificate inventory the week an algorithm is deprecated. Our article on post-quantum encryption in practice covers the algorithm side.

ACME: how automated issuance works

The standard answer to the renewal problem is ACME, the Automatic Certificate Management Environment, defined in RFC 8555. Its abstract describes it as a protocol that lets a certificate authority and an applicant automate domain verification and certificate issuance, and it also covers other tasks such as revocation. The client authenticates with an account key pair and signs its requests as JSON Web Signatures. Servers must support ES256 and should support Ed25519. Each request carries a single-use nonce, and the signed request must name the exact URL it is sent to, which blocks replay.

The order flow in RFC 8555 has four steps. The client submits an order for the identifiers it wants, such as www.example.com. It proves control of each identifier by answering a challenge. It finalizes the order by sending a PKCS#10 certificate signing request. Then it waits for issuance and downloads the certificate. Orders move through the states pending, ready, processing, valid and invalid. The RFC defines two challenge types. With http-01 the client publishes a response at a well-known path on the web server. With dns-01 it publishes a record in the domain's DNS. A third type, tls-alpn-01, was added later in RFC 8737; we did not read that document.

The choice between http-01 and dns-01 is an operational one. http-01 is simple for a single public web server but cannot validate wildcard names and needs port 80 reachable from the validating authority. dns-01 works for wildcards and for hosts that are not reachable from the internet, but the automation then needs credentials to change DNS. Those credentials should be narrow: a token limited to the challenge record or a delegated zone, not the whole DNS account. Delegating the challenge name by CNAME to a separate zone that only the ACME client can edit is a common way to keep the blast radius small. See our article on DNS security for the broader picture.

Building the automation properly

Installing an ACME client is the easy part. The work that keeps a company out of trouble is around it.

• Inventory first. List every public name, every load balancer, content delivery network, appliance, mail gateway and vendor-hosted service that presents a certificate, and who owns each. Certificate transparency logs show every publicly trusted certificate issued for your domains, which makes them a reliable way to find forgotten ones.
• Use the platform's own integration where it exists. Cloud load balancers, managed Kubernetes ingress controllers and many appliances can request and renew certificates natively. A script that copies files to a device is the thing most likely to break silently.
• Monitor expiry independently of the renewal tool. A probe that connects to each endpoint and alerts at, for example, 14 and 7 days remaining catches the case where renewal is failing and nobody noticed. Do not rely on the renewing system to report its own failure.
• Keep private keys where they are used and generate a new key at each renewal when your platform allows it. Reusing a key across renewals weakens the benefit of short lifetimes.
• Treat the ACME account key as a credential. It authorizes issuance for your names, so store it with the same care as a deployment key and rotate it with the account key rollover defined in RFC 8555.
• Test the failure path. Block the challenge on purpose in staging and confirm that alerts fire and an operator can issue by hand. Use CAA records to limit which authorities may issue for your domains.

What cannot be automated easily

Some systems will not renew themselves: an older appliance that accepts a certificate only through a web form, a vendor product that ties certificates to a license, a legacy application server with a keystore that needs a restart. At 47 days these become the weekly work of someone on the team. The options are to replace them, to put an automated terminating proxy in front, or to move the certificate to a layer you control, such as a load balancer. Count these systems now. The number you find is the real cost of the transition, and it is the figure to put in front of whoever owns the budget.

Organization and extended validation certificates have further steps because a human process validates the company. The identity reuse period stays at 398 days from March 2026, so that part is not shortening yet, but the domain validation still repeats on the new schedule. Certificate authorities are building account-level pre-validation for this reason, so ask yours how it handles it.

Internal PKI: your own authority

Not every certificate has to come from a public authority. Services talking to each other inside a network, devices, VPN gateways, wireless authentication and code signing usually use a private PKI, because the clients are under the company's control and trust can be distributed to them. The public schedule does not apply to a private authority, which makes it tempting to issue ten-year certificates and forget them. That is the wrong lesson from SC-081. Short lifetimes for internal certificates are a security control for the same reasons, and ACME works with private authorities too, which lets internal and public certificates share one automation path.

A sound private PKI has a small number of parts. A root authority sits offline, with its private key in a hardware security module, a tamper-resistant device that signs inside itself so that the key is never exported. The root signs one or two intermediate issuing authorities, which run online and issue the day-to-day certificates. The root is switched on only to sign a new intermediate or a revocation list, with more than one person present and a written ceremony. Intermediates can be revoked and replaced without changing what every client trusts. Name constraints on intermediates limit which names they can issue for, which reduces the damage from a compromise.

Decide the policies before the tools: who may request which certificate profile, how identity is checked, how long each profile lasts, how revocation is published and what happens on compromise. Write down the certificate lifetimes and the renewal windows. Run a restore test of the issuing authority's backup, because a lost intermediate key without a backup is a reissue of every certificate it ever signed. For regulated firms, an auditor will ask for these records as evidence of key management.

A plan for the next 12 months

Over the next quarter, build the inventory and the independent expiry monitor, since both are cheap and useful whatever else happens. Over the next two quarters, move every public name that can be automated onto ACME, starting with the public web properties, and replace or front the systems that cannot. Before March 2027, when the cap reaches 100 days, rehearse a failure of your ACME path and confirm that an operator can issue by hand within an hour. Before 2029, decide whether your internal PKI should follow the same lifetimes. None of this is dramatic. It is routine hygiene whose consequences have been moved from once a year to once a month, and it is much easier to start while the lifetimes are still 200 days.

Clayton Cybernetics builds certificate inventories, ACME automation and private PKI with hardware-protected roots for clients, and ties them to the monitoring described in our other infrastructure articles.

Sources

• CA/Browser Forum - Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
• RFC 8555 - Automatic Certificate Management Environment (ACME)

This article is general technical information, not a certificate-management design for your organization. The validity and reuse dates were read in the Relevant Dates table of the current CA/Browser Forum Baseline Requirements (only the first part of that long page was readable, so Sections 4.2.1 and 6.3.2 themselves were not read; the ballot page for SC-081v3 returned an error, and the April 2025 adoption date comes from secondary sources). RFC 8555 was read in part: the challenge and security sections were seen only through the table of contents and an excerpt. RFC 8737 (tls-alpn-01) was not read. The advice on inventories, monitoring, key handling, hardware roots and the 12‑month plan is general engineering knowledge, not quoted from the sources listed. Check the current Baseline Requirements and your certificate authority's policies before planning. Last reviewed November 8, 2026.

Keep reading

Next · InfrastructureNetwork Time for Security and Trading: NTP, NTS and PTPTime is a dependency that most networks never examine until something breaks. Logs from different systems cannot be correlated if clocks disagree, Kerberos and TLS fail when clocks drift, and financial firms must prove their clocks were accurate when a trade was recorded. Three protocols cover the range: NTP for general purposes, NTS to authenticate it, and PTP for sub-microsecond needs. This article explains how each works, what the U.S. and European regulators actually require of trading firms, and how to build and monitor a time service you can defend.10 min read

• Penetration Testing Explained for Executives: Scope, Reports and How Often to Test8 min
• Ransomware Readiness and Incident Response: A Checklist Based on the CISA #StopRansomware Guide9 min