Where does certificate lifetime reduction stand?
The point at which manual renewal must end is not determined by certificate count. If even one expired certificate can stop production, people are needed throughout issuance, validation, and distribution, and there is no independent check that the new certificate is live, manual renewal should already be removed from the normal path.
Publicly trusted TLS server certificates issued on or after March 15, 2026 have a maximum validity of 200 days. Current CA/Browser Forum Baseline Requirements schedule reductions to 100 days on March 15, 2027 and 47 days on March 15, 2029.[7] Those later stages have not taken effect, and the Forum leaves room to revise future schedules if needed. Do not treat future dates as operating facts already in force.
Shorter lifetimes do not merely require operators to press renewal buttons more often. Teams must know where certificates are used, automate issuance and domain validation, keep private keys within appropriate boundaries, distribute certificates to every TLS termination point, and verify actual service delivery. Failures need safe rollback or recovery with a new certificate. This complete flow is Certificate Lifecycle Management.
The latest Baseline Requirements are v2.2.9, effective August 6, 2026.[6] The table shows the current schedule. The 200-, 100-, and 47-day periods are maximums. The Forum defines a day as 86,400 seconds, and even a slight overrun can count as another day, so the corresponding recommended default issuance periods do not exceed 199, 99, and 46 days.[1] DigiCert and Sectigo changed their current maximum issuance period to 199 days before or alongside the March 2026 transition.
The table does not directly govern every private certificate. The Baseline Requirements cover publicly trusted TLS certificates authenticating internet-accessible servers; private PKI using internal-only root CAs falls outside that direct scope. Organizations may adopt shorter internal lifetimes and automation as a separate policy choice.
Issuance date | Maximum public TLS validity | Maximum domain/IP validation reuse | Status on August 27, 2026 |
|---|---|---|---|
| Before March 15, 2026 | 398 days | 398 days | Past stage |
| March 15, 2026 through March 14, 2027 | 200 days | 200 days | Currently effective |
| March 15, 2027 through March 14, 2029 | 100 days | 100 days | Scheduled in current BR |
| On or after March 15, 2029 | 47 days | 10 days | Scheduled in current BR |
Has policy already reached implementation?
This change is no longer only a future discussion. Chromium’s current certificate-verification code implements the 200-day limit for 2026, 100-day limit for 2027, and 47-day limit for 2029 based on issuance dates. Mozilla Root Store Policy also requires included CAs to comply with current Baseline Requirements.
From March 15, 2027, the Chrome Root Program requires each included TLS certificate profile to support automated issuance and renewal. Profiles supporting ACME must support the principal RFC 8555 operations and RFC 9773 ACME Renewal Information.[2] This concerns CA automation capabilities; it does not require website operators to use a particular ACME client.
Actual CA issuance periods already differ. DigiCert and Sectigo currently apply a maximum of 199 days, while Let’s Encrypt’s default profile remains 90 days. Some one-year products or subscriptions provide repeated issuance of individual certificates lasting no more than 199 days. Purchase duration is not the certificate’s notBefore–notAfter validity period.
Shape delivery around the content — Set caching by update behavior and observe edge delivery alongside origin load.
Does certificate count determine when manual renewal should end?
A rule that ten certificates need automation but one can remain manual is unsafe. One certificate can still interrupt a payment API, administrator page, public website, or customer integration endpoint. The table lists signals for removing manual renewal from the normal path.
Human involvement itself is not the problem. People should own certificate policies, domain approvals, exceptions, security incidents, and emergency recovery. Remove the dependence of routine issuance and renewal on a particular person’s calendar, email, memory, and sequence of manual steps.
Manual renewal can remain a temporary exception only when all these conditions hold: low production-interruption risk; one clearly identified endpoint and distribution target; primary and backup owners; independent expiry alerts checking the actual service certificate; sufficient retry and verification time; previously exercised replacement, revocation, and emergency-reissuance procedures; and a recorded exception expiry date and automation owner. Missing any condition makes manual renewal unresolved operating debt, not a long-term model.
Current situation | Possible problem | Default decision |
|---|---|---|
| The certificate handles production traffic | Owner absence or omitted work interrupts service | Automate routine issuance and renewal |
| Multiple targets such as CDN, load balancer, ingress, or servers | Partial deployment leaves some targets serving old certificates | Automate distribution and per-target verification |
| Two or more teams, such as DNS, security, and infrastructure, are involved | Approval and work queues consume remaining validity | Automate workflow and responsibility boundaries |
| People enter DNS TXT records manually | Renewal stops during leave, nights, or change freezes | Use a DNS API or dedicated validation structure |
| People download and copy certificate files manually | Private-key exposure, incorrect chains, or missed targets | Use secret-distribution paths and atomic switching |
| Only portal or local-file expiry dates are monitored | Old certificates still served by load balancers or CDNs go unnoticed | Verify actually served certificates externally |
| The only failure plan is redeploying the old certificate | Expired, revoked, or compromised certificates cannot be rolled back | Separate rollback from emergency issuance |
Does adopting ACME complete lifecycle automation?
ACME, Automatic Certificate Management Environment, is an open standard for automating certificate management. RFC 8555 defines account creation, orders, proof of domain control, CSR submission, certificate download, and revocation requests.[2] Ordinary domain-validated certificates can be requested, validated, and issued online without separate human intervention. ACME connectivity alone does not complete the lifecycle.
The flow starts with inventory, followed by issuance policy and owners, ACME orders, HTTP-01 or DNS-01 challenges, key and CSR generation, issuance, and certificate and chain pre-validation. Certificates are then distributed to all TLS termination points and verified on the live service. Renewal and expiry monitoring, rotation, rollback, revocation, emergency issuance, retirement, and audit complete the flow.
ACME standardizes the issuance transaction. It does not automatically determine the organization’s certificate holdings, owners, target load balancers and CDNs, partial deployment failures, or whether old certificates remain safe. The goal is not installing a client. It is automatic issuance, validation, distribution, and live verification when renewal becomes due, with failure states reaching owners and triggering safe retries or recovery.
How should HTTP-01 and DNS-01 be selected?
Choose by where domain control can be proved safely and repeatedly, not by which challenge seems more modern. The table compares them.
RFC 8555 HTTP-01 serves an account-key-linked value at a specified challenge path.[2] Port 80 access, redirects, IPv4 and IPv6 addresses, and consistency across frontends affect implementation. Let’s Encrypt documentation also states that HTTP-01 does not support wildcards and that multiple web servers must all provide the challenge file.[5]
DNS-01 works with wildcards and private web endpoints, but DNS permissions become a new high-risk secret. Placing a credential capable of changing an entire zone on a web server greatly expands the impact of compromise. Where possible, delegate a dedicated _acme-challenge zone through CNAME or NS and use record-scoped credentials or a separate validation server. Include DNS propagation in the renewal window.
DNS-01 that requires someone to log into a portal and add TXT records manually is ACME at the protocol level but remains manual operations. For routine production renewal, remove repeated work through a DNS API, a dedicated delegated zone, or a separate validation service.
Dimension | HTTP-01 | DNS-01 |
|---|---|---|
| Validation method | Serve a token response at /.well-known/acme-challenge/ | Provide a TXT record under _acme-challenge |
| Required permissions | Control the target web endpoint’s HTTP path | Permission to change the relevant DNS record |
| Network requirements | The CA must reach port 80 | TXT must propagate to authoritative DNS |
| Wildcard certificates | Not supported | Supported |
| Multiple frontends | All validation frontends need the same response or a central validation route | Validation can be independent of web frontends |
| Private web endpoints | Generally unsuitable | Usable when DNS is publicly verifiable |
| Typical risks | Blocked port 80, incorrect redirects, missing responses on some frontends | Broad DNS API credentials, propagation delays, stale records |
| Suitable environments | Simple public web servers, central ingress, automatic HTTP route control | Wildcards, many frontends, private origins, separation of issuance from web runtime |
Why are private keys and automation credentials different secrets?
Distinguish the four secrets listed here. Under RFC 8555, an ACME client signs server requests with an account key and submits a separate CSR during issuance.[2] Let’s Encrypt explicitly prohibits reusing an account key as a certificate key.[5]
Where the private key is generated depends on TLS termination and security requirements. It may be generated at the termination point without export, within central secret management or an HSM/KMS boundary for delivery only to approved targets, or managed by a CDN or managed load balancer.
Whatever the model, inventory must record where the private key resides and who can read or replace it. An HSM is not the answer everywhere, but tickets, messaging, shared folders, and ordinary CI logs must not become normal key-distribution paths.
- ACME Account Key / Credential
- A secret enabling certificate orders, authorization management, and, depending on implementation, revocation. Restrict CA, account, and domain scope and protect it in automation.
- Certificate Private Key
- The key proving endpoint identity and terminating TLS. Keep it at the termination point or within an approved central key-management boundary.
- DNS API Credential
- Credentials permitting DNS changes, including ACME TXT records. Restrict them to least privilege for _acme-challenge and use a dedicated zone where possible.
- Deployment Credential
- Credentials distributing certificates and keys to load balancers, CDNs, secret stores, and appliances. Limit targets and operations and retain audit records.
What belongs in Certificate Inventory?
Inventory is not an expiry-date list. It is an operating ledger connecting certificates, services, keys, validation rights, distribution targets, and recovery paths.[4] The list specifies eighteen fields.
Inventory limited to certificates searchable in a CA portal will omit assets. Certificates automatically issued by managed CDNs or cloud load balancers, certificates remaining on old appliances, and certificates for unused legacy hostnames still need management when they remain in traffic or trust relationships.
- Certificate ID
- A stable internal identifier.
- Service / Environment
- The service and whether the certificate is for production, staging, or development.
- Names
- FQDNs, SAN list, and wildcard status.
- TLS Termination Point
- Where TLS ends: CDN, load balancer, ingress, reverse proxy, web server, or appliance.
- Exposure
- Public internet, partner-only exposure, or internal private PKI.
- CA / Account / Profile
- Issuing CA, ACME account, certificate profile, and relationship to products or subscriptions.
- Current Certificate
- Serial, fingerprint, notBefore, notAfter, issuer, and chain.
- Key Boundary
- Generation and storage locations, exportability, and key version.
- Challenge
- HTTP-01 or DNS-01, validation endpoint, DNS zone, and credential reference.
- Owner
- The final accountable owner and backup.
- Distribution Targets
- Every endpoint, region, and cluster receiving the certificate and key.
- Renewal Policy
- ARI use, Renewal Start, Escalation, and Last Safe Deployment.
- Monitoring
- Live-certificate verification locations and alert owner.
- Rollback
- Storage of the previous healthy certificate and chain, and end-of-use conditions.
- Revocation
- Revocation authority, submission path, and incident approver.
- Emergency Issuance
- Emergency accounts, credentials, distribution paths, and execution owner.
- Lifecycle State
- Current state: Planned, Active, Renewing, Failed, Revoked, or Retired.
- Evidence
- Latest successful issuance, distribution, and external-verification times and work records.
What does a Lifecycle Runbook promise?
This runbook is a repeatable operating agreement for public TLS certificates, not instructions for a particular CA interface. Each of seventeen stages, from scope registration to regular audit, defines standard work, completion evidence, and failure action. Stages without a failure action eventually return to human improvisation.
Stage | Standard work | Completion evidence | Failure action |
|---|---|---|---|
| 1. Register scope | Create a Certificate ID before deploying a new domain, endpoint, or service; distinguish public TLS from private PKI. | Inventory record, service, environment, names, exposure | Unregistered certificates must not pass issuance or deployment gates. |
| 2. Assign owners | Define service, automation, and DNS owners and backups. Make one final accountable owner explicit. | Owner and backup, on-call and escalation routes | Alert on absent owners as operating risk, including departures or transfers, rather than treating it as a renewal exception. |
| 3. Set issuance policy | Define allowed CAs, accounts, profiles, SAN scope, wildcards, key algorithms, and key-reuse policy. | Approved policy ID and change record | Do not deploy out-of-policy issuance; review the cause. |
| 4. Design challenges | Select HTTP-01 or DNS-01 and verify network, propagation, wildcard, and multiple-frontend conditions. | Challenge test and required route/DNS permissions | Restore dedicated validation paths when HTTP routes or DNS APIs fail instead of bypassing them manually. |
| 5. Set credential boundaries | Separate account keys, certificate private keys, DNS tokens, and deployment credentials. | Secret references, scopes, access policies, rotation records | Revoke and replace suspected exposed credentials and investigate affected issuance scope. |
| 6. Generate keys and CSRs | Generate keys in approved locations and CSRs with correct SANs and algorithms. | Key version, CSR digest, requested domains | Stop issuance if generation or CSR validation fails. Do not move temporary key files to shared paths. |
| 7. Execute issuance | Use ACME or an approved API for orders, authorization, and finalization; apply backoff and deadlines rather than infinite retries. | Order ID, authorization result, issued serial | Distinguish rate limits, CAA, DNS, and permission errors and route them to owners. Escalate to an incident if unresolved before Last Safe Deployment. |
| 8. Validate issued artifacts | Check SAN, validity, issuer, chain, key/certificate match, allowed algorithms, and policy. | Pre-deployment validation PASS | Do not deploy incorrect certificates. Reissue where needed and decide whether misissued certificates require revocation. |
| 9. Distribute | Deploy versioned artifacts or secrets to every CDN, load balancer, ingress, server, and region. | Per-target acknowledgement and version | Do not record partial deployment as complete success. Stop expansion and separate failed targets and traffic paths. |
| 10. Activate and verify live | Activate limited targets, then check serial, fingerprint, chain, and expiry through real TLS connections with SNI; distinguish IPv4, IPv6, and key regions. | External live probes match expected fingerprints | Stop traffic expansion if serving is incorrect. Roll back only if the previous certificate is safe; otherwise recover forward. |
| 11. Operate renewal windows | Use ARI when supported; otherwise calculate Renewal Start, Escalation, and Last Safe Deployment from internal lead times. | Next window and job schedule | Do not wait for expiry alerts after the first failure. Alert on retry budget and remaining safe time together. |
| 12. Complete rotation | Confirm new certificates across all targets, then record the old certificate/key end-of-use time. | Intended serial across the fleet; previous version inactive | Treat endpoints still serving old serials as partial-deployment incidents. |
| 13. Roll back or recover forward | Allow limited rollback only while the old certificate is valid, unrevoked, uncompromised, and appropriate for current domains and chains. | Rollback conditions checked; external reverification | Use new keys and certificates for forward recovery when old keys leaked or certificates were revoked. |
| 14. Revoke | Request revocation through approved paths for key exposure, unauthorized issuance, incorrect names or details, and certificates no longer trusted. | Revocation request, CA result, inventory update | Escalate failed revokeCert or emergency-CA paths to a security incident; use CA support and alternative trust paths. |
| 15. Issue in emergencies | Use separate emergency rights, accounts, and contacts to issue a new key and certificate; deploy narrowly and verify externally. | Emergency record, new serial, affected endpoints | If emergency issuance fails, use traffic isolation, checked alternative endpoints, or prevalidated issuance paths. |
| 16. Retire | Remove certificates, keys, DNS challenge delegation, ACME authorization, and deployment secrets when domains or services retire. | Decommission evidence; inventory marked Retired | Do not mark retirement complete while DNS or legacy endpoints remain. |
| 17. Audit regularly | Reconcile inventory with DNS, endpoints, Certificate Transparency, and cloud assets to find unknown certificates and ownership gaps. | Reconciliation result, exceptions, deadlines | Keep unknown certificates under security review until service, owner, and issuance paths are established. |
Operations connected from observation to improvement — Respond using service indicators and alerts, then connect change records and incident reviews to improvements.
Can renewal always start N days before expiry?
Certificates have different validity periods and operational lead times. Applying the same 30-day renewal rule to 199-, 90-, and 45-day certificates can be too late or unnecessarily early.
RFC 9773 ACME Renewal Information lets CAs provide recommended renewal windows per certificate.[3] It supports load distribution and earlier renewal for mass revocation or early replacement. When the CA and client support it, prefer ARI to a fixed cron date.
Without ARI, calculate the last safe deployment time by subtracting maximum domain-validation delay, approval and change waits, deployment time to all targets, retry budget, freezes and holidays, and an incident buffer from notAfter. Define three times: Renewal Start for normal automation, Escalation Deadline for immediate human escalation after continuing retry failures, and Last Safe Deployment as the last opportunity through normal change procedures. notAfter is not a renewal deadline; it is when service failure begins.
Let’s Encrypt currently prioritizes ARI and otherwise recommends renewal with a proportion of certificate lifetime remaining as a fallback for its certificates.[5] This is its operating guidance, not a universal 30-day rule for every CA. Spread issuance and renewal jobs for large fleets and divide batches so failures do not propagate simultaneously across every certificate.
Why are issuance and deployment success different states?
An ACME order becoming valid does not mean the service is using the new certificate. The lifecycle requires four independent success signals.
Expiry monitoring must inspect more than local files or a CA portal. Connect through actual user paths with SNI and check the served notAfter, serial, fingerprint, and chain. Distinguish partial failures: new certificates on IPv4 but old ones on IPv6; new certificates in Seoul but old ones elsewhere; a new CDN-edge certificate but an expired direct-origin certificate; secret reload failures on some Kubernetes ingresses; one load-balancer listener using the wrong certificate ID; or a deployed certificate with an incorrect intermediate chain.
Alongside a single alert such as 30 days to expiry, alert on missing scheduled renewal starts; authorization, CAA, or DNS-challenge failures; issuance completed without deployment starting; only some targets updated; served serials differing from inventory targets; old certificates served after rotation closure; and reaching escalation or last-safe-deployment deadlines.
- Issuance Success
- The CA issued the correct certificate.
- Artifact Validation Success
- SAN, chain, validity, and private key match expectations.
- Distribution Success
- Every CDN, load balancer, ingress, and server received the new version.
- Live Serving Success
- Actual endpoints serve the new serial and correct chain from an external client’s perspective.
Are some certificates ineligible for rollback?
A failed new deployment does not justify unconditional reactivation of the old certificate. Rollback requires that it is unexpired, unrevoked, not suspected of private-key exposure, appropriate for current domains and service configuration, served with a client-trusted chain, and usable for enough time after rollback.
If a new SAN or chain is wrong and the previous certificate satisfies those conditions, a brief rollback is possible. If the old key leaked or its certificate was revoked, rollback reactivates a security incident. Generate a new key and certificate and recover forward instead. Deployment rollback principles likewise exclude leaked or revoked secrets from rollback targets.
Even versioned certificate and key artifacts require explicit conditions ending their usability. An old private key retained indefinitely becomes another attack asset rather than a recovery mechanism.
Why do revocation and emergency issuance need separate runbooks?
Replacement and revocation are different operations. ACME defines revokeCert and supports revocation requests using the account key or certificate key.[2] During incidents, the organization must decide which certificate to revoke and when, whether to isolate traffic first, and which path will issue its replacement.
Typical revocation triggers include confirmed or suspected private-key exposure, unauthorized issuance, incorrect domains, SANs or organization details, loss of domain ownership or operating rights, copies on untrusted systems, and requests from the CA or security team.
Emergency issuance has eight steps. First, declare the incident and freeze ordinary changes, distinguishing expiry risk, key exposure, and unauthorized issuance. Second, use inventory to identify certificates sharing keys, ACME accounts, DNS tokens, SANs, or distribution paths. Third, replace exposed credentials, investigating account keys, DNS API tokens, and deployment credentials as well as certificate keys. Fourth, issue a new key and certificate without reusing a compromised key. Use an alternate CA only when its trust chain, CAA, client compatibility, and deployment path have been validated in advance.
Fifth, deploy to limited endpoints and verify the new serial, SAN, chain, handshake, and service-health signals. Sixth, weigh availability against attack risk before revocation: prioritize isolation and revocation during active exploitation, but prepare a safe replacement first for a deployment-only error. Seventh, recheck every distribution point, including long-lived connections, caches, old load balancers, IPv6, and legacy hostnames. Eighth, update inventory and incident records with causes, exposure time, revocation results, new serials, prevention work, and owners.
An alternate CA is not universally necessary. It adds accounts, CAA records, chains, contracts, issuance policies, and audit scope. Multiple CAs become meaningful recovery options when outage, regulatory, or client-compatibility requirements exist and the actual transition path has been tested.
Should managed certificates remain in inventory?
CDNs, PaaS, and managed load balancers may issue and renew certificates without customers running their own ACME clients. Organizational lifecycle responsibility still remains.
At minimum, know which hostnames are covered, where TLS terminates, who reports issuance and renewal failures, which DNS records and permissions validation needs, what happens during migration or account closure, who verifies live serving, and whether an emergency path exists for vendor outages or account lockout.
Providers own parts of issuance and key storage. Organizations must own inventory, owners, configuration drift, live-service verification, and recovery paths when changing providers.
Which five questions establish automation completion?
Manual renewal has ended only when all five questions have answers. Are all active certificates and termination points inventoried? Are owners, key locations, and challenge-credential boundaries defined? Do issuance, validation, distribution, and retries proceed without repeated manual work? Is the actual served certificate checked independently of automation tools? Have revocation and emergency-issuance procedures been tested for cases where old certificates are unsafe?
Shorter lifetimes are not a signal to choose a particular CA. They call for treating certificates as repeatable credential lifecycles within service delivery and security operations, rather than annual purchases. Automate normal issuance and renewal while people focus on policies, exceptions, and incidents. There is no reason to wait for the 47-day stage: the 200-day stage has already begun.
