Why TLS Certificates Are Shrinking to 47 Days
Today I was renewing one of my DigiCert TLS certificates, something I’ve done countless times before without really thinking much about it. Just another routine task sitting in the middle of emails, deployments, dashboards, and all the usual infrastructure work.
But this time, something felt off.
After the certificate was issued, I glanced at the expiration date and immediately noticed the validity period looked shorter than usual. At first I assumed I misread it, or maybe selected the wrong product during checkout. For years, getting a one-year TLS/SSL certificate had become normal. Even after the industry reduced TLS certificate validity to 398 days, most people had already adjusted to that change.
But this certificate wasn’t valid for 398 days.
It was closer to 200 days.
That small detail sent me into a rabbit hole I honestly wasn’t expecting to fall into during a normal certificate renewal. The deeper I looked, the clearer it became that this wasn’t just a DigiCert change or some temporary CA policy adjustment.
The entire TLS ecosystem is quietly moving toward dramatically shorter certificate lifetimes.
And eventually, by 2029, public TLS certificates may only last 47 days.
The CA/Browser Forum Is Quietly Reshaping Internet Security
Most people outside infrastructure or security teams have probably never heard of the CA/Browser Forum.
But almost everyone on the internet depends on decisions made by this group every single day.
The CA/Browser Forum is an industry consortium made up of:
- browser vendors
- certificate authorities
- security companies
Members include companies like:
- Apple
- Mozilla
- DigiCert
- Sectigo
- GlobalSign
This group defines many of the operational and security rules behind public TLS certificates.
They are responsible for major internet-wide changes like:
- deprecating SHA-1 certificates
- removing weak cryptography
- reducing certificate lifetimes
- enforcing stricter validation standards
The certificate validity reduction timeline has slowly evolved over the years:
| Period | Maximum TLS Certificate Validity |
|---|---|
| Old internet era | 5–10 years |
| 2015 | 39 months |
| 2018 | 825 days |
| 2020 | 398 days |
| Emerging transition | ~200 days |
| Target by 2029 | 47 days |
At first glance, shortening TLS/SSL certificate validity sounds annoying more than anything else.
Why create more renewals?
Why increase operational overhead?
But once you understand what happens when certificates get compromised, the reasoning becomes much clearer.
What Happens When a TLS Certificate Gets Compromised?
A TLS certificate by itself is not the dangerous part.
The real risk is the private key attached to it.
If attackers steal the private key associated with a certificate, they can potentially:
- impersonate the legitimate website
- intercept encrypted traffic
- perform man-in-the-middle attacks
- deploy convincing phishing infrastructure
- bypass user trust warnings
And historically, this has happened multiple times across the industry.
Real Cases Where Certificates Became Dangerous
There have been multiple real-world incidents where stolen or abused certificates were used by attackers to bypass trust systems, distribute malware, or intercept traffic.
DigiNotar Breach (2011)
One of the biggest certificate authority incidents happened when attackers breached DigiNotar, a Dutch CA.
The attackers managed to generate fraudulent certificates for major domains including:
- Yahoo
- Microsoft
One fake Google certificate was reportedly used for large-scale interception and surveillance operations.
Because browsers trusted DigiNotar at the time, affected users would not immediately see security warnings.
The fallout was massive:
- browsers revoked trust in DigiNotar
- governments investigated the incident
- DigiNotar eventually collapsed entirely
The event became one of the biggest wake-up calls in TLS history.
Stuxnet Used Stolen Code-Signing Certificates
The Stuxnet malware used legitimate stolen code-signing certificates from Realtek and JMicron.
Because the malware binaries were digitally signed with trusted certificates:
- Windows treated them as legitimate software
- security tools became less suspicious
- the malware bypassed certain trust protections
This demonstrated how dangerous stolen certificates can become once attackers obtain trusted identities.
Instead of looking malicious, the malware appeared trusted by the operating system itself.
ASUS ShadowHammer Attack (2019)
In the ASUS ShadowHammer supply chain attack, attackers compromised ASUS software update infrastructure and distributed malware through officially signed updates.
The malicious binaries were signed using legitimate ASUS certificates.
As a result:
- the malware looked like a trusted ASUS update
- antivirus detection became harder
- users installed malware without suspicion
Hundreds of thousands of systems reportedly received the malicious updates before the attack was discovered.
SolarWinds Supply Chain Attack (2020)
The SolarWinds compromise became one of the most significant modern supply chain attacks.
Attackers inserted malware into legitimate Orion software updates distributed to customers worldwide.
Because the updates were signed legitimately:
- customers trusted the software
- enterprise security systems allowed deployment
- attackers gained footholds inside government and enterprise networks
The incident highlighted how trusted software signing and machine identity can become powerful attack vectors when compromised.
Compromised VPN and Internal Certificates
In enterprise breaches, attackers frequently target internal certificates after gaining access.
Stolen certificates may include:
- VPN authentication certificates
- internal PKI certificates
- service mesh identities
- SSO authentication certificates
Once attackers obtain them, they can:
- impersonate legitimate systems
- move laterally across networks
- maintain persistence quietly
- bypass MFA in some environments
- evade identity-based detections
In modern Zero Trust infrastructure, certificates effectively become machine passports.
And if attackers steal those identities, they inherit trusted access across the environment.
Why Shorter TLS Certificate Validity Helps
One of the biggest reasons behind the TLS certificate validity reduction is reducing the risk of compromised TLS/SSL certificates and stolen private keys.
When attackers successfully steal a TLS certificate private key, they may be able to:
- impersonate legitimate websites
- intercept encrypted HTTPS traffic
- perform man-in-the-middle attacks
- maintain persistence inside enterprise environments
- abuse trusted machine identities
Under older TLS/SSL certificate validity models, compromised certificates could remain trusted for months or even years. That created a massive attack window for threat actors, especially when certificate revocation systems failed or were ignored.
In theory, compromised TLS certificates can be revoked using:
- OCSP (Online Certificate Status Protocol)
- CRLs (Certificate Revocation Lists)
But in practice, revocation has always been one of the weakest parts of the public PKI ecosystem. Some applications do not properly check revocation status, while others continue operating even if revocation services are unreachable.
This is one of the main reasons the CA/Browser Forum is pushing toward short-lived TLS certificates and eventually 47-day TLS/SSL certificates by 2029.
With shorter certificate validity:
- stolen certificates expire much faster
- attacker persistence becomes harder
- compromised machine identities have a shorter lifespan
- organizations rotate credentials more frequently
Instead of relying entirely on revocation systems, the modern approach is increasingly focused on automatic expiration and continuous certificate rotation.
This shift aligns heavily with modern cybersecurity principles such as:
- Zero Trust security
- ephemeral credentials
- workload identity
- machine identity management
- automated certificate lifecycle management
The future of TLS is clearly moving toward short-lived certificates, automated PKI, and continuously rotating machine trust.
The Real Goal: Force the Internet to Automate
Honestly, after reading deeper into the CA/Browser Forum discussions, it feels obvious this is also about forcing automation.
Because manual certificate management simply cannot survive in a 47-day world.
A surprising number of organizations still rely on:
- spreadsheets
- renewal reminder emails
- ticket approvals
- manual uploads
- maintenance windows
- human deployment processes
That may work for yearly renewals.
It completely breaks when certificates rotate every month.
Modern infrastructure now requires:
- automated issuance
- automated renewals
- certificate discovery
- dynamic trust distribution
- machine identity lifecycle management
This is why tools and standards like:
- ACME
- cert-manager
- Vault PKI
- SPIFFE/SPIRE
are becoming increasingly important.
The Biggest Problem: Most Companies Are Not Ready
One of the biggest challenges with the TLS certificate validity reduction is that many organizations still lack proper certificate inventory and certificate lifecycle management.
Many enterprises still do not fully know:
- how many certificates they own
- where certificates are deployed
- which systems are internet-facing
- which teams manage renewals
Certificates are often hidden inside:
- old load balancers
- forgotten subdomains
- legacy appliances
- embedded systems
- shadow IT infrastructure
As certificate validity periods shrink, those visibility gaps become operational risks.
Because every certificate renewal is also:
- a deployment event
- a potential outage event
- a possible automation failure point
And we’ve already seen countless outages caused by expired certificates across the industry.
The Future of TLS Is Continuous Rotation
I think 47-day TLS certificates are only the beginning of a much larger shift toward automated certificate rotation and short-lived machine identities.
The internet is clearly moving toward:
- ephemeral credentials
- workload identity
- automated trust systems
- continuous authentication
- dynamic machine identity
Some environments may already rotate certificates:
- daily
- hourly
- automatically during deployments
The old “set and forget” SSL certificate model is slowly disappearing as the industry moves toward automated certificate management and short-lived TLS certificates.
And honestly, that shift became very real the moment I saw the unexpected 200-day validity period during what I thought was just another routine DigiCert certificate renewal.
Building a Certificate Automation Platform
One thing I realized while reading about the CA/Browser Forum roadmap toward 47-day TLS certificates is that manual certificate distribution simply will not scale anymore.
Especially with wildcard certificates, where the same certificate often gets deployed across:
- load balancers
- reverse proxies
- Kubernetes ingress
- API gateways
- multiple application servers
In many environments, the process is still manual:
renew certificate → export bundle → copy files → restart services.
That workflow already causes outages today, and shorter certificate validity will only make it worse.
Because of that, I’ve been building a private project focused on certificate automation and secure certificate distribution internally.
The idea is simple:
- centralized certificate inventory
- automated certificate deployment
- renewal synchronization
- expiration monitoring
- secure wildcard certificate distribution
The project is still private and work in progress for now.
But if you’re dealing with similar problems around, feel free to contact me.
