The Certificate Authority Browser Forum has officially blessed us with the internet equivalent of mandatory daily dental flossing: SSL certificates that expire every 47 days by 2029. That’s right. The same certificates that currently give you a comfortable 398 days to procrastinate are about to need replacing—to abuse my dental hygiene conceit—more often than your toothbrush. While the security benefits of shorter certificate lifespans are clear, the operational reality of implementing automation across diverse, legacy-laden infrastructure will be heavy.
This isn’t just another boring security update buried in a GitHub changelog. This is a fundamental reshaping of how the internet handles security, and it’s about to make life very annoying interesting for anyone who manages websites without a CDN and isn’t positioned to pay for often-pricey managed services. Examples of these include AWS Certificate Manager, Virima, ManageEngine Key Manager Plus, DigiCert Trust Lifecycle Manager, AppViewX CERT+, and Keyfactor Command. So let’s chat about SSL Certificates in 2025: Who are the major players? What is the timeline for this rollout? How did we get here? Why are SSL Certificates so important?
From “Set It and Forget It” to “Set It and Sweat It”
“Baseline Requirements,” Certificate Authority, Wikipedia.
The internet was a simpler place back in 1995 when Netscape introduced SSL certificates. Back then, certificates could live for years. Those were the VeriSign days, the first public Certificate Authority. VeriSign controlled over 3 million certificates at its peak before selling its authentication business to Symantec in 2010 for $1.28 billion, only for Symantec to spectacularly self-destruct by 2017 due to improper certificate issuance practices. Google accused Symantec of multiple failures in verifying certificates—issues that, it said, created a serious security risk for Chrome users. The entire mess was eventually bought by DigiCert for $950 million. Since the 2010s, the timeline of certificate lifespans has been steadily shrinking. Each baseline reduction was justified by the CA/Browser Forum with increasingly sophisticated security arguments, but the pattern is clear: we’re slowly being boiled like frogs in the pot of perpetual certificate renewal.
Apple is largely responsible for the 398-day limit. In 2020 they decided that 825-day certificates were simply too long, and unilaterally implemented a 398-day limit in Safari. This move effectively forced the hand of the entire internet. It was also a way of bypassing the CA/Browser Forum by saying “we’re doing this our way.”
Within months, the industry scrambled to comply because nobody wanted their websites marked as “Not Secure” in Safari. Now, Apple has done it again with Clint Wilson, Senior Technical Program Manager at Apple, proposing Ballot SC-081v3, which passed the CA/Browser Forum overwhelming support: 25 votes in favor, 0 votes against, and a few abstaining. The phased implementation timeline reads like a countdown to automation or doom:
- March 15, 2026: 200-day maximum
- March 15, 2027: 100-day maximum
- March 15, 2029: 47-day maximum
Apple’s justification is technically sound but practically terrifying. They argue that certificates are becoming increasingly unreliable over time. They also point out that current revocation systems (CRL and OCSP) are about as reliable as a chocolate teapot, so shorter lifespans provide “firm protection to users independent of certificate status services.” What they don’t mention is that this creates an automation-or-die scenario where manual certificate management becomes untenable. According to Matthew McPherrin, Technical Lead for the Let’s Encrypt Certificate Authority SRE team:
One big industry problem that’s been going on for the last year or two is that CAs have found themselves in situations where they need to revoke certificates because of issues with those certificates, but customers aren’t able to respond on an appropriate timeline. So the big motivation for a lot of the parties here is to get these timelines down and really prove a push towards automation.
Google Chrome, meanwhile, has become the stern enforcer of certificate policies. Chrome’s Certificate Transparency requirements and “Not Secure” warnings have effectively made browser compatibility a non-negotiable requirement for any serious web presence. But it is the post-quantum cryptography transition waiting in the wings like the final boss in a video game that is really at issue. The National Institute of Standards and Technology (NIST) has finalized the first 3 post-quantum cryptographic standards, and organizations need to prepare for cryptographic algorithm transitions that make current certificate management challenges look simple.
Post-quantum certificates will likely be significantly larger (potentially 10x the current size), require new validation processes, and need coordinated deployment across the entire internet infrastructure. The 47-day certificate timeline isn’t just about security, it’s about building the automation infrastructure necessary for rapid cryptographic transitions when quantum computers make current encryption obsolete. Organizations that implement comprehensive certificate automation for 47-day certificates will be more prepared for post-quantum transitions.
Developer sentiment: “If Apple want their certs. to expire every five minutes, that’s on them, why should I be forced to arse about?”
What are practitioners saying? Community reaction to 47-day certificates reads like the comments section of a post about mandatory 6 AM team meetings. One Hacker News user wonders:
What’s the end game here? I agree with the dissent. Why not make it 30 seconds?
Once we cross the threshold of “I absolutely have to automate everything or it’s not viable to use TLS anymore”, why do we care about providing anything beyond ~48 hours? I am willing to bet money this threshold will never be crossed.
This feels like much more of an ideological mission than a practical one, unless I’ve missed some monetary/power advantage to forcing everyone to play musical chairs with their entire infra once a month…
But sentiments are mixed in the way that “mixed” describes a cocktail of resignation, technical acknowledgment, and existential dread. I enjoyed The Register’s forum on the subject (which is where I got my section headline). According to another commenter there:
I think a large proportion of TLS certs out there are free these days … this is just an admin headache if you manage your own certs … if you use CDNs like Cloudflare, Akamai et al, this won’t make a difference at all.
There seems to be a universal acceptance of this change, but recognition that many sysadmins will have a lot more overhead when it comes to managing these changes. There’s also grudging acceptance of the security benefits. Most developers acknowledge that current certificate revocation lists (CRL) are unreliable, and many accept that shorter certificate lifespans imposed by certificate authorities (CAs) do provide legitimate security improvements. But this isn’t universal. One Redditor expresses suspicion against what they term “the unaccountable CA/BF cabal”:
They are literally run by CAs (and browser vendors, the biggest of which is now a CA too), and get to make rulings that require more constant renewal of the products they sell. It doesn’t get more corrupt than this.
Although this sentiment is extreme, with another Redditor replying “I think this is a bit paranoid. Not a lot, just a bit. :),” practitioner frustration is loud. It’s true that many security die-hards and CISOs will rejoice, but the IT practitioners, sysadmins, and web developers tasked with implementing these new rules are less than sanguine.
ACME & The Automation Imperative
The move to 47-day certificates isn’t just a policy change: it’s a forcing function that makes manual certificate management obsolete. Moving from 398-day to 47-day certificates represents an 8.46x increase in renewal frequency. If you currently spend one afternoon per quarter dealing with certificate renewals, you’re now looking at spending more than one full day per month on certificate management. And that’s assuming nothing goes wrong.
One challenge is that according to Cyberark, only 8% of organizations currently fully automate all certificate management, meaning 92% of organizations are about to discover whether their chosen solution actually works under pressure.
The Internet Engineering Task Force’s Automatic Certificate Management Environment (ACME) protocol (RFC 8555) has emerged as the industry standard for automated certificate management. It is pioneered by Let’s Encrypt and now supported by most major Certificate Authorities. But ACME implementation comes with its own collection of issues:
- HTTP-01 challenges require port 80 access
- DNS-01 challenges need API access to your DNS provider
- Legacy system integration ranges from “challenging” to “archaeologically impossible”
- Load balancer automation Vendors like Oracle Load Balancer offer no native ACME support
In other words, while ACME has become the de facto path forward, its practical hurdles—especially in complex, mixed-age environments—mean most organizations can’t just flip a switch to compliance. With certificate lifespans shrinking to weeks, the real question isn’t whether automation is necessary, but which vendors can tame the operational chaos without introducing new risks of their own.
Vendor Strategies for Certificate Chaos
Who will engineering leaders look to to automate their SSL certificates? There’s lots of services in the space, so let’s discuss the SSL certificate landscape in 2025. Since the 90s, the domain of SSL certificate providers has evolved from a cozy oligopoly led by VeriSign to something resembling a gladiatorial arena.
Let’s Encrypt, “a Certificate Authority that provides free TLS certificates,” revolutionized the CA space when they appeared in 2016. This service is supported by sponsors including Google, AWS, Sovereign Tech Agency, Open Technology Fund, Alpha-Omega, Mozilla, EFF, OVHcloud, and the Internet Society Foundation. Unsurprisingly, Let’s Encrypt has been an extremely popular solution and now issues over 5 million certificates monthly and controls 63.7% of the Certificate Authority market according to W3 Techs Web Technology Surveys. In terms of market share, Global Sign (23.1%) and Sectigo, formerly Comodo SSL (6%), maintain respectable second and third place.
Cloudflare has positioned itself as the Switzerland of SSL certificates, offering Universal SSL that automatically handles certificate management for any domain on their platform. Their approach is simple: route your traffic through Cloudflare, and certificates become their problem, not yours. AWS Certificate Manager used to take a walled garden approach, providing free certificates that work beautifully within the AWS ecosystem and nowhere else, but in June they announced “public certificates you can use anywhere.” These are valid for 395 days, they cost $15 per FQDN and $149 per wildcard name. Google Cloud offers the first 100 certificates free, then $0.20/month per certificate up to 2,000, then $0.10/month beyond that.
DigiCert has evolved from a traditional Certificate Authority to a comprehensive platform provider. Their DigiCert Trust Lifecycle Manager promises to handle everything from ACME-compatible systems to legacy hardware that predates the internet. Sectigo Certificate Manager promises to make “managing digital certificates effortless—even in the face of 47-day TLS lifespans, where complexity increases 12-fold.” ZeroSSL similarly promises to “Issue and renew free 90-day SSL certificates in under 5 minutes & automate using ACME integrations and a fully-fledged REST API.” CertKit solves the impending certificate management chaos by “fully automat[ing] certificate management, renewal, and monitoring.”
From free, community-backed initiatives to premium enterprise platforms, the SSL ecosystem has never offered more options—or more complexity. Yet a crowded field doesn’t guarantee a smooth transition to 47-day certificates. For many enterprise and SMB teams, the coming shift will expose brittle processes, half-finished automation, and hidden dependencies that no amount of vendor marketing can wish away. The next few years will separate those with truly resilient certificate strategies from those about to learn some painful lessons in uptime.
Enterprise, the “Missing Middle,” & Embedded Systems
The approach to 47-day certificates will prove tremendously challenging for many enterprise companies. Enterprise change approval processes often take longer than 47 days to complete, creating a fundamental incompatibility between organizational governance and certificate lifespans. IT engineers report situations where submitting a change request and getting CAB (Change Advisory Board) approval takes 2-3 months. This will doubtless make 47-day certificates operationally impossible without exempting certificate renewals from normal change management. According to one Hacker News user:
Where I use to work, certs are a nightmare.
For example, some sites were closed and we asked the site owner to revoke their cert. We got “What does that mean ?”, they had lost their private key.
Also other departments had certs that expired, they had no idea what to do. I left over a year ago, and someone who knows more about certs that I do left not long afterwards. I know many certs are due expire soon, good luck to them.
The point of this is I can see 45 day certs being a huge issue for that company. When I left they were looking into non-expiring certs. I have no idea what they ended up doing.
FWIW, this is a fortune 500 company.
The missing middle market occupying that awkward space between “just use Cloudflare for everything” and “we have a dedicated Public Key Infrastructure (PKI) team,” faces its own challenges in adapting to this transition. I chatted with Todd Gardner, CEO of Request Metrics and TrackJS, about this situation. He created Certkit, and is particularly concerned about what he terms the “missing middle.” This large but often overlooked segment of companies—think manufacturers, gyms, banks, insurers—run mixed, aging infrastructure spread across multiple clouds and on-prem systems. They may not be coveted enterprise accounts or tech darlings, but they still have to meet the new 47-day certificate rules. For many, buying an all-in CA solution isn’t feasible, leaving them to engineer automation that bridges decades-old systems and modern platforms with minimal manual effort—or face an endless renewal cycle.
Here’s where the 47-day certificate timeline transitions from “challenging” to “potentially catastrophic”: embedded systems, industrial control systems, and medical devices that were designed when certificate lifespans were measured in years, not weeks. These IoT systems often have manual certificate installation processes that require physical access, scheduled maintenance windows, and approval processes that take longer than 47 days to complete. Imagine trying to update certificates on wind turbines, manufacturing equipment, or medical devices every month and a half. Although private CAs are exempt from this 47-day limitation, not all medical device manufacturers use them. This has resulted in some quiet panicking because FDA-approved devices can’t have major updates without 501(k) regulatory approval processes that make 47-day certificate cycles look lightning-fast. Similarly, building management systems controlling HVAC, security, and fire safety often run embedded controllers on public certificates that update about as frequently as building renovations.
For all of these reasons some folks are kicking around the nuclear option of internal PKI for systems that don’t need public trust, effectively creating their own certificate authorities for internal use. These may resemble the Federal Public Key Infrastructure (FPKI), which “includes U.S. federal, state, local, tribal, territorial, and international governments, as well as commercial organizations, that work together to provide services for the benefit of the federal government.” Internal PKI solutions like FPKI, [John] Deere & Company PKI, and Apple PKI trade certificate management complexity for PKI management complexity, which is like solving traffic problems by building your own roads. As the deadlines shorten we may see more enterprise organizations adopt this strategy.
Conclusion: Automation or Obsolescence
The 47-day certificate transition represents a fundamental shift in internet infrastructure management from periodic maintenance to continuous automation. Organizations that adapt early will gain competitive advantages through more robust, automated infrastructure. Those that delay face operational disruptions, increased security risks, and the eventual realization that manual certificate management has become as obsolete as manually calculating payroll.
Disclaimer: Google, AWS, Microsoft, GitHub, Akamai, and Cloudflare are RedMonk clients.