For most of the history of commercial web hosting, SSL certificate management has been relatively simple.
A customer purchased a certificate, the hosting company installed it, and—until relatively recently—it could remain in place for a year or longer before anyone needed to think about it again.
That model is disappearing.
The web security industry has begun a multi-year transition that will reduce the maximum lifetime of publicly trusted SSL/TLS certificates to just 47 days by March 2029. Even more significantly, the period during which previously completed Domain Control Validation can be reused will eventually shrink to only 10 days.
For web hosting companies, this is far more than another certificate-policy change.
It represents a fundamental change in how SSL certificates will have to be provisioned, renewed, monitored and sold.
By the end of this transition, SSL certificate management must become an automated hosting-platform function rather than a manual administrative task.
Who Is Making the Rules?
The organization at the center of these changes is the CA/Browser Forum, generally abbreviated as the CA/B Forum.
The CA/B Forum brings together two groups that effectively control the publicly trusted certificate ecosystem:
-
Certificate Authorities such as DigiCert, Sectigo and GlobalSign.
-
Browser and operating-system vendors including Apple, Google, Mozilla and Microsoft.
The Forum publishes the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates.
Certificate Authorities that want their certificates trusted by major browsers are effectively required to operate within these requirements as well as the individual policies of browser and operating-system root programs.
The current reduction schedule resulted from Ballot SC-081v3, originally proposed by Apple and approved by the CA/B Forum in April 2025. The ballot establishes a phased reduction in both certificate validity and the amount of time that previous domain validation information may be reused. (CA/Browser Forum)
This distinction is important.
The CA/B Forum is technically a voluntary industry organization. However, browser vendors ultimately determine which Certificate Authorities their software trusts. If Chrome, Safari, Firefox or Edge refuses to trust a certificate, that certificate has little practical value on the public web.
That gives browser vendors enormous influence over the certificate ecosystem.
The New SSL Certificate Timeline
The reduction is occurring in three major stages.
| Effective Date | Maximum Public TLS Certificate Validity | Maximum Domain/IP Validation Reuse |
|---|---|---|
| March 15, 2026 | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
The first stage has therefore already happened.
Since March 15, 2026, newly issued publicly trusted TLS certificates have been limited to a maximum validity period of 200 days.
On March 15, 2027, that maximum falls again to 100 days.
Finally, on March 15, 2029, maximum certificate validity falls to only 47 days, while reusable Domain Control Validation information falls dramatically to 10 days. These dates and limits are now incorporated into the CA/B Forum Baseline Requirements. (CA/Browser Forum)
That means the traditional concept of buying and installing a certificate once per year is rapidly becoming obsolete.
What Does a 47-Day Certificate Actually Mean?
It does not necessarily mean customers will purchase a new SSL product every 47 days.
Commercial Certificate Authorities can continue selling annual or multi-year certificate subscriptions.
A hosting company might therefore sell a customer something described commercially as:
Sectigo SSL – 1 Year
But the certificate installed on the customer's server cannot remain valid for that entire year.
Instead, several individual certificates will need to be issued during the subscription period.
Today, under the 200-day maximum, a commercial certificate subscription will generally require at least two certificate deployments during a year.
Beginning in 2027, the 100-day maximum pushes the industry toward roughly quarterly replacement.
By 2029, hosting providers should assume certificates will be replaced approximately monthly.
Sectigo itself describes the 47-day environment as a monthly renewal model and warns that manual certificate administration becomes increasingly impractical as certificate lifetimes shrink. (Sectigo® Official)
And a responsible hosting platform should never wait until Day 46 to begin replacing a 47-day certificate.
Certificates should be renewed well in advance of expiration to provide time for validation, issuance, deployment and failure recovery.
Consequently, operational renewal intervals may be considerably shorter than the theoretical maximum certificate lifetime.
Domain Validation Is Changing Too
One of the most consequential parts of SC-081v3 receives far less attention than the 47-day certificate itself.
That is the shrinking Domain Control Validation reuse period.
Before a Certificate Authority issues a Domain Validated certificate, it must establish that the applicant controls the domain.
Validation can be performed through mechanisms such as:
-
DNS records,
-
HTTP validation,
-
or other CA/B Forum-approved validation methods.
Historically, successful domain validation could be reused for a substantial period.
That reuse period is shrinking along with certificate validity.
Beginning March 15, 2029, domain and IP validation information may generally be reused for only 10 days. (CA/Browser Forum)
That creates an important architectural consequence.
It will not be sufficient for a hosting control panel simply to remember that:
“We validated this domain last month.”
The platform must be capable of performing domain validation again automatically as part of the certificate renewal process.
DNS APIs, HTTP challenges and automated ACME validation therefore become increasingly important.
ACME Moves From Convenience to Infrastructure
Fortunately, the hosting industry already has a technology designed for exactly this problem.
It is the Automatic Certificate Management Environment, better known as ACME.
ACME allows software to:
-
Request a certificate.
-
Prove control of the domain.
-
Obtain the certificate.
-
Install it.
-
Monitor its expiration.
-
Replace it automatically.
Let's Encrypt helped make ACME widely used by issuing free 90-day certificates and encouraging automated renewals.
Google Trust Services and numerous commercial Certificate Authorities now support ACME-based certificate issuance as well.
What was once primarily viewed as a convenient way of obtaining free SSL certificates is becoming a core component of hosting infrastructure.
By 2029, a hosting platform without reliable automated certificate lifecycle management will be operating at a major disadvantage.
Manual SSL Installation Is Becoming Economically Impossible
Consider a small hosting provider managing only 500 domains.
Under a conventional annual certificate model, that might historically mean approximately 500 certificate renewal events every year.
At a 47-day maximum lifespan, the same environment could involve thousands of certificate replacements annually.
Even if each certificate required only ten minutes of administrative work, the labor requirement would become substantial.
For a provider operating tens of thousands of domains, manual management is simply unrealistic.
And the largest risk isn't labor.
It is failure.
Every certificate replacement introduces possibilities including:
-
validation failure,
-
DNS failure,
-
incorrect certificate installation,
-
missing intermediate certificates,
-
application server configuration errors,
-
load balancer synchronization failures,
-
certificate/private-key mismatches,
-
or simply forgetting to perform the renewal.
An expired TLS certificate can immediately present browser security warnings to customers and effectively make a website unusable.
The frequency of these events therefore turns certificate automation into a reliability requirement.
The Economics of SSL Are Also Changing
There is another misconception surrounding shorter certificates:
A 47-day certificate does not necessarily mean customers will pay eight or twelve times as much for SSL.
Commercial Certificate Authorities are increasingly separating the commercial subscription period from the technical certificate validity period.
A hosting customer might still purchase twelve months of SSL coverage.
The Certificate Authority simply issues multiple certificates during those twelve months.
Therefore, the major cost increase may not come from the certificate itself.
It comes from certificate lifecycle management.
Hosting companies will increasingly spend money and development effort on:
-
ACME integration,
-
certificate inventory systems,
-
monitoring,
-
DNS automation,
-
renewal engines,
-
Certificate Lifecycle Management platforms,
-
failure recovery systems,
-
alerting,
-
and certificate deployment automation.
The economic value is moving from the individual certificate file toward the system managing the certificate.
Free SSL Will Become Even More Dominant
This change will also accelerate an existing trend in shared hosting.
For ordinary Domain Validated certificates, customers increasingly have little reason to purchase certificates manually.
Let's Encrypt already provides automated, publicly trusted certificates at no charge.
As the entire public TLS ecosystem moves toward shorter certificates, the operational difference between a paid DV certificate and a free automated DV certificate becomes smaller.
For many hosting companies, the logical default becomes:
Every hosted domain receives automated SSL automatically.
Paid certificates will not disappear, however.
There will still be markets for:
-
Organization Validated certificates,
-
Extended Validation certificates,
-
enterprise certificate management,
-
contractual warranties,
-
specialized support,
-
certificate discovery and governance,
-
private PKI,
-
regulated enterprise environments,
-
and organizations requiring specific Certificate Authorities.
But selling a basic DV certificate primarily as a manually installed file will become increasingly difficult to justify.
Hosting Control Panels Need to Change
The biggest implications may therefore fall on control-panel developers.
In the 47-day world, SSL cannot simply be a page containing:
Generate CSR
Upload Certificate
Upload Private Key
Install Certificate
Those tools may remain necessary for advanced administrators, but they can no longer represent the primary certificate workflow.
Modern hosting platforms should instead maintain a certificate lifecycle service.
At minimum, that system should include:
Automatic discovery
The platform should know every domain and service requiring TLS.
That includes more than websites.
Certificates may be required for:
-
web servers,
-
mail servers,
-
control panels,
-
webmail,
-
APIs,
-
FTP services,
-
load balancers,
-
reverse proxies,
-
containerized applications,
-
and customer applications.
Automated issuance
When a domain becomes active, the system should automatically obtain an appropriate certificate.
Automated validation
HTTP-01, DNS-01 and other approved validation mechanisms should operate without administrator intervention wherever possible.
Automated deployment
Certificates must automatically reach Apache, Nginx, mail servers, proxies and any other service using them.
Automated renewal
Renewal should occur sufficiently early that there is time to recover from problems before expiration.
Verification
Installing a new certificate is not enough.
The platform should verify that the certificate actually being presented by the service is the newly issued certificate.
Monitoring and alerting
Administrators should have a central dashboard showing:
-
valid certificates,
-
expiration dates,
-
renewal status,
-
failed validations,
-
failed installations,
-
issuer information,
-
and certificates approaching expiration.
The objective should be simple:
A hosting administrator should almost never need to renew a certificate manually.
DNS Automation Will Become Increasingly Valuable
DNS integration becomes particularly important as DCV reuse falls to only ten days.
Hosting companies controlling both DNS and hosting have an enormous advantage because they can perform DNS-based domain validation automatically.
Providers should therefore consider integrating APIs for popular DNS platforms such as:
-
Cloudflare,
-
Route 53,
-
Google Cloud DNS,
-
Azure DNS,
-
and their own authoritative DNS infrastructure.
DNS-01 validation is particularly useful for wildcard certificates because HTTP validation cannot provide the same functionality in every situation.
Hosting platforms should also securely manage temporary ACME challenge records and remove them after successful validation.
Certificate Inventory Becomes a Security Function
Another consequence of shorter certificate lifetimes is that hosting providers need to know exactly which certificates exist.
Organizations frequently have certificates administrators have forgotten about.
They may exist on:
-
forgotten development servers,
-
old subdomains,
-
internal tools,
-
staging systems,
-
abandoned load balancers,
-
mail services,
-
or customer-managed applications.
This is sometimes called certificate sprawl or shadow certificates.
A modern hosting security system should therefore continuously discover certificates, identify their owners and monitor their expiration.
Certificate management increasingly becomes part of infrastructure security rather than simply account administration.
Hosting Companies Should Begin Preparing Now
The industry has until March 2029 before the 47-day maximum arrives, but waiting until 2029 would be a serious mistake.
The transition has already started.
Hosting companies should use the current 200-day environment to test their automation architecture.
A sensible migration path would be:
2026 — Inventory and automate
Identify every certificate being managed and eliminate manual renewal wherever possible.
2027 — Stress-test automation
When certificate validity falls to 100 days, renewal events become frequent enough to expose weak automation quickly.
Track failed renewals and eliminate manual intervention.
2028 — Prepare for monthly lifecycle management
Assume certificates will soon rotate approximately monthly. Integrate certificate monitoring with infrastructure monitoring and incident alerting.
2029 — Operate SSL as an automated service
By the time the 47-day maximum takes effect, normal certificate issuance and replacement should require no human intervention.
This Is More Than an SSL Change
The move toward 47-day certificates reveals a larger change occurring across internet infrastructure.
Security credentials are becoming increasingly short-lived, automated and disposable.
The old security model was based around issuing something and trusting it for a long time.
The emerging model assumes credentials should expire quickly and be continuously regenerated.
That philosophy appears across modern infrastructure in:
-
short-lived authentication tokens,
-
ephemeral cloud credentials,
-
automatic secret rotation,
-
automated certificates,
-
workload identities,
-
and zero-trust architectures.
The SSL certificate is becoming another automatically rotated credential.
The Opportunity for Hosting Companies
For hosting providers, the new rules present an operational challenge—but also an opportunity.
A hosting company that builds certificate lifecycle automation correctly can make the entire transition invisible to its customers.
The customer should not need to understand 200-day certificates, 100-day certificates, 47-day certificates, ACME challenges or DCV reuse periods.
They should simply see:
SSL Protection: Active
Behind that message, the hosting platform should continuously validate, issue, install, verify and rotate certificates automatically.
That is likely to become an important distinction between modern hosting platforms and legacy hosting systems.
By 2029, the question hosting providers ask will no longer be:
“How easy is it to install an SSL certificate?”
The better question will be:
“Why would anyone ever need to install one manually?”
The CA/B Forum's move toward 47-day certificates effectively answers that question.
The future of SSL/TLS management is not shorter certificates.
The future is certificate automation.
The key dates in the article come directly from the CA/B Forum's adopted requirements rather than relying solely on CA marketing material. The 200-day limit has already been in force since March 15, 2026; the next important deadline is March 15, 2027, when it drops to 100 days. (CA/Browser Forum