The 47-day certificate is coming: what hosting providers need to build now

Publicly trusted TLS certificates are on a fixed schedule from a maximum lifetime of 398 days down to 200 days, then 100 days, and finally 47 days in March 2029. The first step has already happened. Since March 15, 2026, no public certification authority will issue a server certificate valid for more than 200 days, and the rules governing how CAs validate domain control have tightened at the same time.

For a company managing a handful of service hostnames, this is a calendar adjustment. For a hosting provider responsible for millions of customer domains, mail servers, control panels, webmail instances, and MTA-STS policy hosts, it is an infrastructure change. Certificate issuance stops being an annual maintenance task and becomes a continuous, high-volume production workload with its own availability requirements.

We run email infrastructure for hosting providers, so we spend a lot of time thinking about certificates on mail servers, where a failed renewal does not produce a browser warning. It produces deferred mail, silent downgrades to weaker transport security, or both. In this post we walk through the CA/Browser Forum timeline, do the issuance math at hosting scale, and describe the systems we think providers need to have running well before 2029: automated DNS validation, multi-region preflight checks, external deployment verification, and a secondary CA that has actually been tested.

The schedule below comes from the CA/Browser Forum Baseline Requirements for publicly trusted TLS server certificates, version 2.2.8, dated June 16, 2026, available at cabforum.org.

This is a certificate-management change, not a new TLS protocol

Administrators still say “SSL” out of habit, but these requirements apply to publicly trusted TLS server certificates: the credentials your servers present when a client connects.

They do not change how TLS itself works. SMTP STARTTLS negotiation, IMAP and POP, cipher suites, MTA-STS policy syntax, S/MIME certificates, and anything issued by your own private internal PKI are all untouched. Your mail software will keep speaking TLS exactly as it does today.

What changes is the machinery around the certificate: how CAs confirm that you control a domain, how long that evidence stays fresh, how many network vantage points the CA must check from, and how long the resulting certificate lives. That machinery now has to run roughly eight times a year per certificate instead of once, and it has to tolerate far less downtime.

What changes, and when

Several of these requirements are already in effect as of July 2026.

Effective date	Change
March 15, 2026	Maximum certificate lifetime reduced to 200 days. Domain-validation reuse reduced to 200 days. DNSSEC validation became mandatory for the primary CA perspective’s domain-control and CAA lookups. Multi-perspective validation expanded to at least three remote perspectives.
June 15, 2026	CAs must use at least four remote network perspectives for applicable domain and CAA checks.
September 15, 2026	Remaining SHA-1 signatures in certificates and CRLs are prohibited.
December 15, 2026	CAs must use at least five remote network perspectives.
March 15, 2027	Maximum certificate lifetime and domain-validation reuse fall to 100 days. CAs must process the CAA accounturi and validationmethods parameters. Remaining phone-based validation and several IP-address validation methods are retired.
March 15, 2028	Constructed-address email validation and DNS-published certificate-validation email methods are prohibited.
March 15, 2029	Maximum certificate lifetime falls to 47 days. Domain-validation evidence may be no more than 10 days old.

The certificate lifetime is the headline. At hosting scale, though, we expect the validation and DNS requirements to cause more failures than the shorter lifetime itself. The rest of this post explains why.

Issuance becomes a production workload

A certificate’s maximum lifetime sets a floor on how many times it must be issued each year.

Maximum lifetime	Issuances per certificate per year	Relative to 398 days
398 days	0.92	1x
200 days	1.83	2x
100 days	3.65	4x
47 days	7.77	8.5x

A provider with one million individually certified customer hostnames therefore needs at least 7.8 million certificate issuances per year once 47-day certificates arrive. That is roughly one issuance every four seconds, around the clock, forever.

And that is only the theoretical floor. It excludes early renewals, failed validation attempts, retries, key rotation, staging and test issuance, certificate name changes, and emergency replacement after a compromise or a CA incident. Even a 99.9% first-attempt success rate leaves about 7,800 failed attempts per year, roughly 21 every day, each of which needs automated retry logic and, eventually, a specific human-readable explanation.

One open question we cannot answer yet is how CA rate limits and issuance capacity will evolve when the entire industry’s order volume rises roughly eightfold. Plan for the possibility that they do not scale gracefully.

Certificate issuance can no longer be a cron job wrapped around an ACME client. It becomes a distributed production system with its own state management, retry semantics, observability, capacity planning, and failure domains. A mature certificate control plane has to coordinate inventory and renewal scheduling, ACME accounts and CA APIs, challenge provisioning, authoritative DNS updates, private-key generation and protection, certificate and chain retrieval, distribution to every serving node, zero-downtime TLS reloads, external verification of what each edge actually presents, and revocation with emergency replacement.

That last point deserves emphasis. The certificate in your database is not necessarily the certificate on your edge. At scale, deployment verification matters as much as successful issuance.

The 10-day validation window matters as much as the 47-day certificate

By March 2029, a CA can reuse domain-control validation evidence for no more than 10 days. In practice, almost every issuance will require a fresh confirmation that the subscriber still controls the domain.

The two numbers are easy to conflate, so to be precise: the certificate may remain valid for up to 47 days, but the CA’s evidence of domain control must be no more than 10 days old at the moment the next certificate is issued.

If your platform controls the customer’s authoritative DNS, this is workable. If your renewal process depends on a customer pasting a TXT record into a third-party DNS console, it is not. Nobody is going to do that every six weeks, correctly, forever.

The design goal is a one-time delegation: the customer performs a single authorization step at onboarding, and every subsequent validation is completed automatically by infrastructure you control. We come back to the mechanics below.

DNS is now on the certificate availability path

Since March 15, 2026, CAs must perform DNSSEC-validating lookups for domain-control and CAA checks from their primary validation perspective. DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS data so that resolvers can verify a response has not been tampered with. It provides integrity, not privacy.

This does not force your customers to deploy DNSSEC. An unsigned zone still validates. What it means is that a signed-but-broken zone can now block certificate issuance outright.

The failure modes are familiar to anyone who has survived a DNS provider migration: a stale or incorrect DS record at the parent, expired signatures, keys that vanished during the move, algorithm mismatches, authoritative servers that disagree with each other, incorrect denial-of-existence responses, intermittent SERVFAIL responses, and CNAME chains that cross signed and unsigned zones. Historically, a customer could run partially broken DNSSEC for months without noticing, because most of their users sat behind permissive or non-validating resolvers. Under the new rules, a CA cannot look the other way and issue anyway.

For a hosting provider, this makes DNSSEC health a certificate-renewal dependency. A renewal preflight should classify each domain: correctly signed, unsigned, DNSSEC-bogus, inconsistently served across authorities, or returning different answers from different networks. Checking the record through the single recursive resolver in your data centre no longer tells you what the CA will see.

Multi-perspective validation will find your inconsistent infrastructure

CAs must also corroborate domain-control and CAA results from multiple remote network perspectives. Since June 15, 2026, that means at least four remote perspectives spanning at least two Regional Internet Registry service regions, with at most one perspective allowed to disagree with the primary result. On December 15, 2026, the minimum rises to five.

The intent is to defeat certificate misissuance caused by BGP hijacking and other network-local attacks. The side effect is that ordinary configuration inconsistencies, the kind that never mattered before, now block issuance. A TXT challenge that propagated to only some of your authoritative servers. Geo-DNS handing different validation targets to different regions. An anycast deployment with one stale site. Split-horizon DNS accidentally exposed to public resolvers. An HTTP challenge installed on part of a web cluster, or reachable over IPv4 but not IPv6. CAA records that differ between authoritative servers. A firewall or geoblocking policy that quietly rejects the CA’s validation traffic from one continent.

A challenge that succeeds from your office or your primary cloud region can still fail at the CA. We recommend building your own multi-region preflight service. It does not need to replicate a CA’s validation network exactly, but it should query authoritative DNS and probe challenge endpoints from genuinely diverse networks before an order is submitted, so that any disagreement is your finding rather than the CA’s.

Email-based certificate approval is being retired

This one lands close to home for anyone in the email business. Beginning March 15, 2028, CAs may no longer approve issuance by sending a message to constructed addresses such as admin@, administrator@, webmaster@, hostmaster@, or postmaster@ the target domain. Validation using email contacts published through DNS CAA or TXT records is prohibited as well.

Those methods suited small, manually administered environments. They cannot survive contact with 47-day lifetimes and a 10-day evidence window. The replacements are DNS- and endpoint-based automation, typically through ACME (Automatic Certificate Management Environment, defined in RFC 8555): DNS challenge records, delegated _acme-challenge names, account-labelled DNS challenges where the CA supports them, persistent domain-validation records, HTTP challenges, and TLS-ALPN challenges.

For mail-only hostnames, we prefer DNS validation. A mail server may not run an HTTP listener at all, and routing certificate challenges for your MX through an unrelated web tier creates coupling you will regret during an incident.

Prefer one-time DNS delegation

The practical pattern: ask the customer, once, to create a CNAME or other supported delegation beneath a validation-specific label, pointing at a zone you control. From then on, you satisfy every challenge yourself, on your own authoritative servers, with no further customer interaction.

The exact construction depends on the CA and the validation method, but the architectural objective is constant: customer authorization should be durable, while each individual CA validation stays fresh and automated.

The Baseline Requirements also define a persistent TXT-record method under a _validation-persist label. The record identifies the authorized CA and subscriber account, and can optionally include an expiration timestamp:

_validation-persist.example.com. IN TXT \
  "authority.example; accounturi=https://authority.example/acct/123"

“Persistent” does not mean the CA can rely on an old DNS observation forever. It means the customer does not have to publish a fresh random value for every issuance. The CA still performs a current lookup each time and confirms the record remains present and valid.

CAA can block both routine renewal and emergency failover

CAA (Certification Authority Authorization) records let a domain owner declare which certification authorities may issue for the domain. Beginning March 15, 2027, CAs must also process two parameters from RFC 8657: accounturi, which restricts issuance to a particular subscriber or ACME account, and validationmethods, which restricts the permitted domain-control validation method.

These are good security controls, and they will fail renewals in new ways. The CA is authorized but your specific ACME account is not. A regional issuance system uses a different account URL. The customer’s CAA permits http-01 while your pipeline uses DNS validation. The account was recreated during a migration and nobody updated the records. Your emergency secondary CA is not listed at all, or is listed without its account URI. Wildcard and non-wildcard policies differ and nobody noticed.

Inspect the complete effective CAA policy at onboarding and continuously afterward. And treat failover claims with suspicion: a secondary CA is not a real failover path just because your ACME client has a configuration stanza for it. The alternate CA, its ACME account, the validation method, the CAA authorization, the trust chain, the issuance capacity, and the deployment path all have to be proven in advance. An untested secondary issuer is documentation, not redundancy.

Mail systems do not all fail the same way

A certificate failure on a web server produces an immediate, visible browser error. Mail is less obliging, and the failure mode depends on the protocol and the sender’s policy.

Opportunistic SMTP. Traditional server-to-server SMTP mostly uses opportunistic TLS. Depending on the sending MTA’s policy, an expired or untrusted certificate may not stop delivery at all. Mail may keep flowing encrypted but without authenticated identity, fall back to a weaker TLS policy or even cleartext, defer temporarily, or be rejected outright. The dangerous case is the quiet one: everything appears to work while the security properties of the connection silently degrade. This is why certificate failures on MX hosts routinely go undetected for weeks.

MTA-STS in enforce mode. MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets a domain publish a policy requiring senders to verify that STARTTLS is available, the certificate is valid, and the receiving MX matches the published policy before delivering. A sender honoring an enforce-mode policy will defer mail when your renewal fails, and persistent deferral eventually becomes nondelivery. Worse, senders cache policies, so changing your MTA-STS policy in the middle of an incident does not immediately stop the bleeding.

Submission, IMAP, POP, and webmail. User-facing clients perform conventional certificate and hostname validation for SMTP submission, IMAP, POP, webmail, and autodiscover endpoints. An expired certificate here is immediately visible: warning dialogs at best, refused connections at worst, and a support queue either way.

Manually pinned connections. Some providers and enterprise customers still authenticate SMTP peers by exact leaf-certificate fingerprint. Exchanging a new fingerprint by email every six weeks is not a process, it is a countdown. Bilateral integrations should move toward hostname and CA-based validation, automated pin distribution, stable public-key (SPKI) policies, or DANE with a deliberate rollover procedure.

Naming architecture determines the size of your problem

The cheapest certificate is the one you never have to issue. The most effective lever a hosting provider has is reducing the number of independently certified names.

Put customer mail behind provider-controlled MX hostnames

A customer domain can publish MX records that point at stable names you own:

example.com. IN MX 10 mx1.provider.example.
example.com. IN MX 20 mx2.provider.example.

Now the certificates cover mx1.provider.example and mx2.provider.example rather than every customer domain separately. You control the authoritative DNS, the DNSSEC signing, and the CAA policy for those names. A small certificate set serves millions of customer domains, renewal never depends on customer DNS, and MTA-STS policies can authorize the stable provider MX pattern.

This is, incidentally, how our own services are built. Hosting providers that route customer mail through MailChannels point MX records at hostnames we operate, which means the certificate lifecycle for that path lives entirely on infrastructure we control. We did not design it that way because of the 2029 deadline, but it illustrates the principle this whole transition rewards: every name you move onto DNS you control is a renewal that a customer’s DNS mistake can never block.

The exposure runs the other way with branded customer names such as mx.customer.example, smtp.customer.example, imap.customer.example, mail.customer.example, autodiscover.customer.example, and webmail.customer.example. Every one of those ties a certificate lifecycle to DNS you do not control.

Do not overlook MTA-STS policy hosts

Even with all MX traffic on provider-controlled names, managed MTA-STS requires an HTTPS policy host under each customer’s own domain, conventionally mta-sts.customer.example, and that host needs its own valid publicly trusted certificate. A provider offering managed MTA-STS across millions of domains can therefore end up with an enormous certificate estate even though the SMTP infrastructure itself uses a handful of certificates. Treat the MTA-STS certificate fleet as its own service, with its own issuance capacity, deployment pipeline, and monitoring.

Avoid excessive SAN coupling

Packing many customer domains into one large SAN (Subject Alternative Name) certificate reduces the number of orders, but it couples fates. One failed domain validation blocks the entire renewal. Revocation hits every name at once. A private-key compromise has a wide blast radius. Certificate Transparency logs aggregate your customers’ names in public. Adding or removing a single customer forces reissuance, and deployment becomes harder to shard.

For most large platforms, the better shape is a mix: small provider-controlled certificate sets, carefully scoped wildcards, individually managed certificates for custom names, and sharding by service, region, or failure domain. The objective is not the fewest certificates. It is the smallest operational and security blast radius consistent with an issuance volume you can actually sustain.

What to build now

2029 sounds distant. It is not, because the 200-day regime and the multi-perspective requirements are already live, and each intermediate stage is a rehearsal for the next. Here is what we would build, in order.

1. A complete certificate inventory. Every public TLS endpoint, not just websites: SMTP on ports 25, 465, and 587; IMAP and POP; webmail; hosting control panels; autodiscover; MTA-STS policy hosts; customer APIs; tracking and redirect domains; load balancers and edge proxies; legacy appliances; customer-branded service names. For each name, record the issuing CA, ACME account, validation method, DNS owner, serving nodes, private-key location, renewal policy, and deployment mechanism. You cannot automate what you cannot enumerate.

2. Issuance decoupled from application deployment. Renewing a certificate must not require a normal release. You need independent certificate distribution, overlapping old and new certificates, atomic activation, hot reload, rollback, per-node deployment status, and reconciliation of stale nodes. A certificate counts as deployed only when external probes confirm that every expected edge is presenting it.

3. Renewals as stateful workflows. At scale, every certificate needs a durable state machine:

scheduled
  → order created
  → challenge provisioned
  → validation pending
  → certificate issued
  → distributed
  → activated
  → externally verified
  → previous certificate retired

Retries must be idempotent. A worker restart must not orphan the relationship between the ACME order, the challenge record, the certificate, the private key, and the deployment operation.

4. DNS and CAA preflight checks. Before requesting issuance, test authoritative nameserver agreement, DNSSEC state and validity, CNAME delegation, TXT challenge visibility, IPv4 and IPv6 consistency, the effective CAA policy including accounturi and validationmethods restrictions, wildcard authorization, and visibility from multiple regions and networks. Then return specific failure reasons. “ACME validation failed” is useless to an operator triaging thousands of renewals a day. Useful classifications look like:

NXDOMAIN
SERVFAIL
DNSSEC_BOGUS
CAA_DENIED
CAA_ACCOUNT_MISMATCH
CAA_METHOD_MISMATCH
CHALLENGE_NOT_FOUND
CHALLENGE_VALUE_MISMATCH
PERSPECTIVE_DISAGREEMENT
AUTHORITATIVE_INCONSISTENCY
HTTP_UNREACHABLE
TLS_ALPN_UNREACHABLE

5. A real renewal safety margin. Do not schedule renewal near the end of a 47-day lifetime. The window has to absorb CA outages, DNS propagation, rate limiting, perspective disagreement, deployment failures, weekends, holidays, customer DNS corrections, and failover to another CA. Track both absolute time remaining and percentage of lifetime remaining. A policy that was comfortably safe at 398 days is dangerously late at 47.

6. Monitoring of the certificate actually served. External probes should check expiry, Subject Alternative Names, issuer and chain, presented serial number, hostname matching, TLS negotiation, edge-to-edge consistency, and SNI and non-SNI behavior where relevant. For mail infrastructure, probe SMTP, submission, IMAP, POP, HTTPS, and MTA-STS separately. Never infer the state of your MX certificate from your HTTPS endpoint.

7. A secondary CA that provably works. Exercise the backup CA continuously with canary or non-critical production certificates. Confirm that CAA permits the CA and the correct account, the validation method is allowed, API credentials are current, rate limits are understood, the intermediate chain works with the clients you support, and issued certificates flow through the normal deployment pipeline.

8. Fleet-wide replacement drills. Periodically replace certificates across an entire service class on purpose, and measure it. How fast can you generate new keys? Can the CA sustain the order volume? Can DNS challenges be provisioned quickly enough? Can every edge receive and activate the replacement, and can you find the nodes that did not? Can affected customers be notified? You need these answers for 47-day rotation, and you need them just as much for the next mass-revocation event, CA incident, or weak-key discovery, none of which will wait for 2029.

Certificate management is becoming an availability system

The move to 47-day certificates is usually described as a security-policy change. For hosting providers, it is more honest to call it an infrastructure change. The certificate lifecycle now depends continuously on CA availability, DNS and DNSSEC correctness, CAA policy, ACME account configuration, multi-region reachability, challenge orchestration, private-key management, edge deployment, and external verification. At 398 days, a partly manual process could limp along. At 47 days, manual intervention is an exception handler, not a renewal strategy.

Providers that control their service names, centralize issuance, automate DNS validation, and verify deployments externally will make this transition without drama. Providers that depend on customer tickets, email approvals, annual maintenance windows, and untested DNS assumptions are accumulating a very specific kind of technical debt: the kind with a published due date.

If you take one action this quarter, build the inventory. Then read the Baseline Requirements yourself; the dates in version 2.2.8 are not going to move in your favor. The 200-day era has already begun. Treat it as the dress rehearsal it is.