The 47-Day Certificate Era Starts with a 100-Day Deadline

The public web is about to find out which organizations have a certificate-management system and which have a calendar reminder.

Beginning March 15, 2027, newly issued public TLS certificates will be limited to 100 days. The ceiling falls again to 47 days in March 2029. The change, adopted through the CA/Browser Forum’s baseline requirements, turns a task that many teams could survive doing manually once a year into one that may recur eight or more times annually for every endpoint.

AWS’s timing is deliberate. In June 2026, Certificate Manager added a managed ACME server for public certificates. Standard ACMEv2 clients such as Certbot, cert-manager, and acme.sh can now obtain Amazon Trust Services certificates for workloads running in AWS, on premises, or in another cloud, while PKI administrators govern domain scope and client authority centrally through ACM.

This closes a genuine tooling gap. It does not make the migration automatic. Short-lived certificates expose every brittle installation step, abandoned endpoint, stale owner, broken chain, hard-coded trust store, and monitoring system that confuses issuance with successful deployment. The organizations that start with inventory and renewal proof now will experience 2027 as a policy change. The ones that start with procurement will experience it as an outage program.

The deadline is closer than the headline

The 47-day date attracts attention, but the first operational step arrives much sooner. The CA/Browser Forum schedule caps public subscriber certificates issued on or after March 15, 2027 at 100 days. The maximum domain-control-validation reuse period also contracts over the schedule, reducing how long a certificate authority can rely on an earlier proof of domain control.

At a 100-day maximum, a cautious client renewing with 30 days remaining executes about five cycles per year. At 47 days, renewing 15 days before expiry means roughly eleven opportunities per year for the automation to prove itself. One silently broken deploy hook can become an outage in weeks rather than months.

Shorter validity is designed to reduce exposure when a key is compromised and to force the ecosystem toward automation. It also changes the useful reliability target. A 99 percent successful renewal process sounds excellent until it manages 20,000 certificates eleven times a year. At that scale, a one percent failure rate is 2,200 failed renewal events annually.

What ACM’s managed ACME service adds

ACME, standardized in RFC 8555, is the protocol behind automated certificate authorities such as Let’s Encrypt. The client creates an account, requests a certificate, proves authorization, receives the certificate, and renews it before expiry.

ACM now exposes a managed ACMEv2 endpoint backed by Amazon Trust Services. It separates the workflow into a control plane and a data plane. A PKI administrator creates the endpoint, pre-validates allowed domains through DNS, and generates External Account Binding credentials. An application owner configures a standard ACME client with those credentials and requests a certificate without receiving the organization’s DNS credentials.

Each external account binding is associated with an IAM role, so the organization can constrain what the client may request or revoke. ACM records issuance in its certificate inventory, CloudTrail logs API activity, CloudWatch exposes operational metrics, and expiry notifications provide a backstop. Certificates can be used outside AWS, which makes the service relevant to hybrid and multicloud workloads rather than only load balancers integrated natively with ACM.

The security improvement is not merely automation. It is the separation of duties: the PKI team controls which domains are eligible, while the workload team operates renewal without broad DNS power.

Treat EAB credentials like issuance authority

External Account Binding credentials authorize an ACME client to register against an endpoint. They are not ordinary application configuration. Whoever holds a valid binding can exercise the certificate actions allowed by its associated IAM role and domain scope.

Issue separate bindings per platform or trust boundary rather than sharing one across the enterprise. Give them expirations, tag them with owner and workload, deliver them through a secrets system, and revoke them on decommissioning. Do not bake the HMAC key into a container image or a Git repository. Monitor first use, last use, and unexpected registration patterns.

Domain scope deserves equal care. A binding for one service should not authorize a wildcard covering the company. Prefer narrow fully qualified names when practical; where wildcards are operationally necessary, isolate them behind stricter issuance and deployment controls. The ability to mint a trusted certificate is a production privilege even when the private key never touches AWS.

Inventory is the hard prerequisite

Most enterprises do not have one certificate estate. They have several: ACM-managed load balancers, Kubernetes ingress controllers, appliances, Java keystores, CDN endpoints, partner-managed gateways, old virtual machines, and certificates copied manually into secrets managers. Procurement records find certificates the company bought. They do not find every endpoint serving one.

Build the inventory from the outside in and the inside out. Externally scan approved domains and IP ranges to observe the certificate actually presented. Internally enumerate ACM, Kubernetes secrets and Certificate resources, load balancer listeners, API gateways, ingress controllers, web server configurations, network appliances, and secret stores. Reconcile the two views.

Every record needs an endpoint, certificate fingerprint, issuing CA, not-before and not-after dates, subject alternative names, key algorithm, installation mechanism, renewal mechanism, service owner, business criticality, environment, and last successful deployment proof. “Auto-renew” is not a mechanism; name the client, job, controller, and destination.

Unknown ownership is a severity. A certificate without an owner should enter a burn-down queue even if it has months remaining, because nobody will know whether an automated change is safe when the deadline arrives.

Renewal is not deployment

The most common false green in certificate programs is a newly issued certificate sitting safely in a file or secret while the production endpoint continues to serve the old one. ACME clients can obtain material, but installation may still depend on a deploy hook, sidecar, controller, service reload, appliance API, or human handoff.

Monitor from the client perspective. After every renewal, perform a TLS handshake against each production endpoint, record the served fingerprint and expiry, validate the complete chain, and compare it with the intended certificate. Test every DNS answer and load-balanced path; one stale node behind a healthy fleet is still an incident waiting for traffic.

Measure deployment lag from issuance to verified serving. A certificate issued in seconds but deployed in nine days has a nine-day control loop. Alert on lag, not merely days to expiry.

Design for failed renewals

The system should attempt renewal early enough to survive several independent failures. Use exponential backoff with jitter, but cap it so retries cannot drift past the safe window. Alert on the first persistent failure and again at escalating thresholds tied to business impact.

Define two deadlines. The soft deadline is when routine automation should have succeeded. The hard deadline is the last point at which the incident process can replace the certificate without threatening availability. Owners should be paged against the hard deadline, not sent another low-priority email.

Run failure drills in non-production: revoke a binding, deny an IAM action, break the deploy hook, serve an incomplete chain, and introduce clock skew. Confirm that monitoring distinguishes issuance failure, installation failure, and endpoint verification failure. Those are different responders and different fixes.

Mind the platform edges

Java and embedded clients may pin a trust chain or ship an old trust store. Appliances may require a reboot to load a certificate. Mutual TLS systems may confuse public server-certificate rotation with private client identity. Certificate Transparency monitoring may see authorized high-volume issuance as suspicious unless baselines change.

Kubernetes users should separate cert-manager’s authority by namespace, issuer, and DNS scope. A cluster-wide issuer backed by a broadly authorized binding turns a namespace compromise into certificate issuance across the estate. Network policy and workload identity should restrict which controllers can reach the ACME endpoint and secrets containing the binding.

ACM service quotas also belong in capacity planning. AWS documents quotas for endpoints, bindings, domain validations, and protocol operations. Large fleets should model renewal bursts and distribute them; eleven annual cycles do not need to become eleven synchronized storms.

A migration calendar that leaves room for failure

By the end of the third quarter of 2026, complete discovery and assign owners. In the fourth quarter, select the standard issuance patterns, create scoped ACME endpoints and bindings, and migrate representative workloads from every platform class. During the first quarter of 2027, shorten internal renewal windows voluntarily and run repeated failure drills before the 100-day limit takes effect on March 15.

Track four board-level measures: percentage of externally observed endpoints in inventory, percentage with a named owner, percentage with automated issuance and deployment, and percentage whose last renewal was proven by an external handshake. The fourth number is the one that predicts outages.

The 47-day era is not principally a cryptography project. It is a reliability program with security consequences. ACM’s managed ACME endpoint supplies an important missing control plane, especially for organizations already governed through AWS IAM and Organizations. The durable result still depends on discovering every endpoint, narrowing issuance authority, automating installation, and proving what customers actually receive.

Sources and reporting notes

• AWS announcement: ACME support in Certificate Manager, June 30, 2026.
• AWS ACM ACME architecture and workflow, consulted for control-plane, domain-validation, and EAB behavior.
• AWS Certificate Manager quotas, consulted for fleet planning.
• CA/Browser Forum Baseline Requirements, consulted for the 2027 and 2029 validity schedule.

---

CloudDefender helps teams find the exposed resources, stale ownership, and configuration paths around certificate endpoints, so certificate automation becomes part of a visible security system rather than another hidden job.