TLS certificate lifetimes will officially reduce to 47 days

What&#x27;s the end game here? I agree with the dissent. Why not make it 30 seconds?<p>Once we cross the threshold of &quot;I absolutely have to automate everything or it&#x27;s not viable to use TLS anymore&quot;, why do we care about providing anything beyond ~48 hours? I am willing to bet money this threshold will never be crossed.<p>This feels like much more of an ideological mission than a practical one, unless I&#x27;ve missed some monetary&#x2F;power advantage to forcing everyone to play musical chairs with their entire infra once a month...

Heh, working with a number of large companies I&#x27;ve seen most of them moving to internally signed certs on everything because of ever shortening expiration times. They&#x27;ll have public certs on edge devices&#x2F;load balancers but internal services with have internal CA signed certs with long expire times because of the number of crappy apps that make using certs a pain in the ass.

As I said in another thread, basically that will kill any possibility to do your own CA for your own subdomain. Only the big one embedded in browser will have the receive to have their own CA certificate with whatever period they want...<p>And in term of security, I think that it is a double edged sword:<p>- everyone will be so used to certificates changing all the time, and no certificate pinning anymore, so the day were China, a company or whoever serve you a fake certificate, you will be less able to notice it<p>- Instead of having closed systems, readonly, having to connect outside and update only once per year or more to update the certificates, you will have now all machines around the world that will have to allow quasi permanent connections to random certificate servers for the updating the system all the time. If ever Digicert or Letsencrypt server, or the &quot;cert updating client&quot; is rooted or has a security issue, most servers around the world could be compromised in a very very short time.<p>As a side note, I&#x27;m totally laughing at the following explanation in the article:<p><pre><code> 47 days might seem like an arbitrary number, but it’s a simple cascade: - 47 days = 1 maximal month (31 days) + 1&#x2F;2 30-day month (15 days) + 1 day wiggle room </code></pre> So, 47 is not arbitrary, but 1 month, + 1&#x2F;2 month, + 1 day are not arbitrary values...

I really wish encryption and identity weren&#x27;t so tightly coupled in certificates. If I&#x27;ve issued a certificate, I _always_ care about encryption, but sometimes do not care about identity.<p>For those times when I only care about encryption, I&#x27;m forced to take on the extra burden that caring about identity brings.<p>Pet peeve.

This is great news. This would blow a hole in two interesting places where leaf-level certificate pinning is relied upon:<p>1. mobile apps.<p>2. enterprise APIs. I dealt with lots of companies that would pin the certs without informing us, and then complain when we&#x27;d rotate the cert. A 47-day window would force them to rotate their pins automatically, making it even worse of a security theater. Or hopefully, they switch rightly to CAA.

&gt; As a certificate authority, one of the most common questions we hear from customers is whether they’ll be charged more to replace certificates more frequently. The answer is no. <i>Cost is based on an annual subscription</i> […]<p>(emphasis added)<p>Pump the brakes there, digicert. <i>Price</i> is based on an annual subscription. CA costs will actually go up an infinitesimal amount, but they’re already nearly zero to begin with. Running a CA has got to be one of the easiest rackets in the world.

I see that there is a timeline for progressive shortening, so if anyone has any &quot;inside baseball&quot; on this, I&#x27;m very curious to know:<p>Given that the overarching rationale here is security, what made them stop at 47 days? If the concern is _actually_ security, allowing a compromised cert to exist for a month and a half is I guess better than 398 days, but why is 47 days &quot;enough&quot;?<p>When will we see proposals for max cert lifetimes of 1 week? Or 1 day? Or 1 hour? What is the lower limit of the actual lifespan of a cert and why aren&#x27;t we at that already? What will it take to get there?<p>Why are we investing time and money in hatching schemes to continually ratchet the lifespan of certs back one more step instead of addressing the root problems, whatever those are?

So the assumption here is that somehow your private key is easier to compromise than whatever secret&#x2F;mechanism you use to provision certs?<p>Yeah not sure about that one...

Off-topic: What is a good learning resource about TLS?<p>I&#x27;ve read the basics on Cloudflare&#x27;s blog and MDN. But at my job, I encountered a need to upload a Let&#x27;s encrypt public cert to the client&#x27;s trusted store. Then I had to choose between Let&#x27;s encrypt&#x27;s root and intermediate certs, between key types RSA and ECDSA. I made it work, but it would be good to have an idea of what I&#x27;m doing. For example why root RSA key worked even though my server uses ECDSA cert. Before I added the root cert to a trusted store, clients used to add fullchain.pem from the server and it worked too — why?

Can someone point me to specific exploits that this key rotation schedule would have stopped?<p>It seems to me like compromised keys are rare. It also seems like 47 days is low enough to be inconvenient, but not low enough to prevent significant numbers of people from being compromised if there is a compromised key.

Is there an actual issue with widespread cert theft? That seems like the primary valid reason to do this, not forcing automation.

This change will have a steady roll-out, but if you want to get ahead of the curve then Let&#x27;s Encrypt will be offering 6 day certs as an option soon.<p><a href="https:&#x2F;&#x2F;letsencrypt.org&#x2F;2025&#x2F;02&#x2F;20&#x2F;first-short-lived-cert-issued&#x2F;" rel="nofollow">https:&#x2F;&#x2F;letsencrypt.org&#x2F;2025&#x2F;02&#x2F;20&#x2F;first-short-lived-cert-is...</a>

Don&#x27;t forget the lede buried here - you&#x27;ll need to re-validate control over your DNS names more frequently too. Many enterprises are used to doing this once-per-year today, but by the time 47-day certs roll around, you&#x27;ll be re-validating <i>all</i> of your domain control every 10 days (more likely every week).

So does this mean all of our Chromecasts are going to stop working again once this takes effect since (judging by Google&#x27;s response during the week long Chromecast outage earlier this year) Chromecast is run by a skeleton crew and won&#x27;t have the resources to automate certificate renewal?

Justification:<p>&gt; <i>The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.</i><p>&gt; <i>The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA&#x2F;B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support.</i><p>Personally I don&#x27;t really buy this argument. I don&#x27;t think the web sites that most people visit (especially highly-sensitive ones like for e-mail, financial stuff, a good portion of shopping) change or become &quot;less trustworthy&quot; that quickly.

First impression: with automation and short lived certificates, the Certifying Authorities become similar to Identity Providers &#x2F; OpenID Provider in openid &#x2F; openid-connect. The certificates are tokens.<p>And significant part of security is concentrated around the way Certifying Authorities validate the domain ownership. (So called challenges).<p>Next, maybe clients can run those challenges directly, instead of relying onto certificates? For example, when connecting a server, client client sends two unique values, and the server must create DNS record &lt;unique-val-1&gt;.server.com with record value of the &lt;unique-val-2&gt;. Client check that such record is created and thus the server has proven it controls the domain name.<p>Auth through DNS, that&#x27;s what it is. We will just need to speed up the DNS system.

I don’t see any issue here. I already automate with ACME so rotating certificates on an earlier basis is okay. This should be like breathing for app and service developers and infrastructure teams.<p>Side note: I wonder how much pressure this puts on providers such as LetsEncrypt, especially with the move to validate IPs. And more specifically IPv6…

I&#x27;m sure this will be buried, but SSL is supposed to provide encryption. That&#x27;s it.<p>Self-signed custom certs also does that. But those are demonized.<p>Also SSL also tries to define a ip-dns certification of ownership, kind of.<p>There&#x27;s also a distinct difference between &#x27;this cert expired last week&#x27; and &#x27;this cert doesn&#x27;t exist&#x27; and mitm attack. Expired? Just give a warning, not a scare screen. MITM? Sure give a big scary OHNOPE screen.<p>But, yeah, 47 days is going to wreck havok on network and weird devices.

I know this thread is over, but it&#x27;s important to understand that it&#x27;s the browsers who have all the power in CABF and they were the drivers behind this change. Apple proposed it and Google voted yes within minutes of the voting period opening. It was unanimous among CAs too (with 5 abstentions), and nobody really disagrees with it, but it was the browsers who started the initiative now. The article links to the vote thread: <a href="https:&#x2F;&#x2F;groups.google.com&#x2F;a&#x2F;groups.cabforum.org&#x2F;g&#x2F;servercert-wg&#x2F;c&#x2F;bvWh5RN6tYI" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;a&#x2F;groups.cabforum.org&#x2F;g&#x2F;servercert...</a> And here&#x27;s the CABF discussion before the vote: <a href="https:&#x2F;&#x2F;github.com&#x2F;cabforum&#x2F;servercert&#x2F;pull&#x2F;553&#x2F;commits&#x2F;69cea5473f20e6ea518dbec8ac549d88f8a35830">https:&#x2F;&#x2F;github.com&#x2F;cabforum&#x2F;servercert&#x2F;pull&#x2F;553&#x2F;commits&#x2F;69ce...</a>

Question: Does anyone have a good solution for renewing letsencrypt certificates for websites hosted on multiple servers? Right now, I have one master server that the others forward the well-known requests too, and then I copy the certificate over when I&#x27;m done, but I&#x27;m wondering if there&#x27;s a better way.

Your 90-day snapshot backups will soon become 47-day backups. Take care!

(Shameless self-promotion) We set up our <a href="https:&#x2F;&#x2F;heiioncall.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;heiioncall.com&#x2F;</a> monitoring to give our on-call rotation a non-critical “it can wait until Monday” alert when there are 14 days or less left on our SSL certificates, and a critical alert “do-not-disturb be damned” when 48 hours left until expiry. Because cert-manager got into some weird state once a few years ago, and I’d rather find out well in advance next time.<p>Edit: it’s configured under Trigger -&gt; Outbound Probe -&gt; “SSL Certificate Minimum Expiration Duration”

If this is causing you pain, certbot with Acme DNS challenge is pretty easy to set up to get you certs for your internal services. There are tools for many different dns providers like route53 or cloudflare.<p>I tend to have secondary scripts that checks if the cert in certbots dir is newer than whatever is installed for a service, and if so install it. Some services prefer the cert in certain formats, some services want to be reloaded to pick up a new cert etc, so I put that glue in my own script and run it from cron or a systemd timer.

It sure would be nice if we could actually fix dns.

To me I don&#x27;t really care about the certificate lifetime, what I care about is the time between being allowed to renew and time until expiry.<p>Right now Let&#x27;s Encrypt recommends renewing your 90d certificates every 60 days, which means that there is a 30 day window between recommended to renew and expiry. This feels relatively comfortable to me. A long vacation may be longer than 30 days but it is rare and there is probably other maintenance that you should be doing in this time (although likely routine like security updates rather than exceptional like figuring out why your certificate isn&#x27;t renewing).<p>So if 47 days ends up meaning renew every 17 days and still have that 30 day buffer I would be quite happy. But what I fear is that they will recommend (and set rate limits based on) renewing every 30 days with a 17 day buffer which is getting a little short for comfort IMHO. While big organizations will have a 24h oncall and medium organizations will have many business hours to figure it out is sucks for individuals who what to go away for a few weeks without worrying about debugging their certificate renewal until they get home.

Daniel K Moran figured out the endgame:<p>&quot;Therefore, the Lunar Bureau of the United Nations Peace Keeping Force DataWatch has created the LINK, the Lunar Information Network Key. There are currently nine thousand, four hundred and two Boards on Luna; new Boards must be licensed before they can rent lasercable access. Every transaction--every single transaction--which takes place in the Lunar InfoNet is keyed and tracked on an item-by-item basis. The basis of this unprecedented degree of InfoNet security is the Lunar Information Network Key. The Key is an unbreakable encryption device which the DataWatch employs to validate and track every user in the Lunar InfoNet. Webdancers attempting unauthorized access, to logic, to data, to communications facilities, will be punished to the full extent of the law.&quot;<p>from The Long Run (1989)<p>Your browser won&#x27;t access a site without TLS; this is for your own protection. TLS certificates are valid for one TCP session. All certs are issued by an organization reporting directly to a national information security office; if your website isn&#x27;t in compliance with all mandates, you stop getting certs.

After EFF Lets Encrypt made the change to disable reminder emails I decided I would be moving my personal blog from my VPS to AWS specifically. I just today made the time to make the move and 10 minutes after I find this.<p>I could have probably done more with Lets Encrypt automation to stay with my old VPS but given that all my professional work is with AWS its really less mental work to drop my old VPS.<p>Times they are a changing

A welcome change if it gives some vendors a kick up the behind to implement ACME.

&gt; For this reason, and because even the 2027 changes to 100-day certificates will make manual procedures untenable, we expect rapid adoption of automation long before the 2029 changes.<p>Oh yes, vendors will update their legacy NAS&#x2F;IPMI&#x2F;whatever to include certbot. This change will have the exact opposite effect - expired self signed certificates everywhere on the most critical infrastructure.

Old SysAdmin and InfoSec Admin perspective:<p>Dev guys think everything is solvable via code, but hardware guys know this isn&#x27;t true. Hardware is stuck in fixed lifecycles and firmware is not updated by the vendors unless it has to be. And in many cases updated poorly. No hardware I&#x27;ve ever come across that supports SSL\TLS (and most do nowadays) offers any automation capability in updating certs. In most cases, certs are manually - and painfully - updated with esoteric CLI cantrips that require dancing while chanting to some ancient I.T. God for mercy because the process is poorly (if at all) documented and often broken. No API call or middelware is going to solve that problem unless the manufacturer puts it in. In particular, load balancers are some of the worst at cert management, and remember that not everyone uses F5 - there are tons of other cheaper and popular alternatives most of which are atrocious at security configuration management. It&#x27;s already painful enough to manage certs in an enterprise and this 47 day lifecycle is going to break things. Hardware vendors are simply incompetent and slow to adapt to security changes. And not everyone is 100% in the cloud - most enterprises are only partially in that pool.

The ultimate internet &quot;kill switch&quot;: revoke all certificates. Modern browsers refuse to render the page.

Pretty sure this only refers to publicly trusted certs. What percentage of public certs are still being manually managed?<p>I&#x27;ve been in the cert automation industry for 8 years (<a href="https:&#x2F;&#x2F;certifytheweb.com" rel="nofollow">https:&#x2F;&#x2F;certifytheweb.com</a>) and I do still hear of manual work going on, but the majority of stuff <i>can</i> be automated.<p>For stuff that genuinely cannot be automated (are you sure you&#x27;re sure) these become monthly maintenance tasks, something cert management tools are also now starting to help with.<p>We&#x27;re planning to add tracking tasks for manual deployments to Certify Management Hub shortly (<a href="https:&#x2F;&#x2F;docs.certifytheweb.com&#x2F;docs&#x2F;hub&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.certifytheweb.com&#x2F;docs&#x2F;hub&#x2F;</a>), for those few remaining items that need manual intervention.

Having short-lived certificates is good, replacing them too often is not. This is implemented trivially for single-host deployments which just run certbot or ACME each subdomains. But for sophisticated setups where a certificate for a domain (or multiple domains or a wildcard) must be shared across fleet of hosts, it is a burden.<p>There are no ready-made tools available to automate such deployments. Especially if a certificate must be the same for each of the hosts, fingerprint included. Having a single, authoritative certificate for a domain and its wildcard subdomains deployed everywhere is much simpler to monitor. It does not expose internal subdomains in certificate transparency logs.<p>Unfortunately, organizations (persons) involved in decisions, do not provide such tools in advance.

This sounds an awful lot like security theatre.<p>&gt; The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.<p>This is patently nonsensical. There is hardly any information in a certificate that matters in practice, except for the subject, the issuer, and the expiration date.<p>&gt; Shorter lifetimes mitigate the effects of using potentially revoked certificates.<p>Sure, and if you&#x27;re worried about your certificates being stolen and not being correctly revoked, then by all means, use a shorter lifetime.<p>But forcing shorter lifetimes on everyone won&#x27;t end up being beneficial, and IMO will create a lot of pointless busywork at greater expense. Many issuers still don&#x27;t support ACME.

I wonder how many forums run by the barely able are going to disappear or start charging.<p>I fairly regularly get cert expired problems because the admin is doing it as the yak shaving for a secondary hobby

Getting a bit ridiculous.

Why bother with such a long staggered approach?<p>There should be 1 change from 365 to 47 days. This industry doesnt need constant changes, which will force everyone to automating renewals anyway.

Thanks for the heads up. I will adjust my cron jobs to run every week instead of every month.<p>I need it more frequently to get more time in case there is an error as I tend to ignore the error e-mails for multiple weeks due to my fatigue from handling of various kinds of certificates.<p>Personally I also have an HTTP mirror for my more important projects when availability is more important than security of the connection.

This could be addressed in a more progressive way.<p>For example, EV carts had the green bar that was a soft way to promote their presence&#x2F;use over the normal ones. That bar, started as a strong evidence on the url box and lost that look with the time.<p>Something like that let the owner to decide and, maybe, the user push their use because it feels more secure, not directly the CA.

Will see how Azure FD will handle this. We opened more than expected tickets with support on certs not updating automatically...

This naively (or maliciously perhaps) maintains that the &quot;purpose&quot; of the certificate is to identify an entity. While identity and safeguarding against MITM is important, identity is not the primary purpose certificates serve in the real world. At least that is not how they are used or why they are purchased.<p>They are purchased to provide encryption. Nobody checks the details of a cert and even if they did they wouldn&#x27;t know what to look for in a counterfeit anyway.<p>This is just another gatekeeping measure to make standing up, administering, and operating private infrastructure difficult. &quot;Just use Google &#x2F; AWS &#x2F; Azure instead.&quot;

Continually surprised by how emotional people get about cert lifetimes.<p>I get that there are some fringe cases where it’s not possible but for the rest - automate and forget.

All I care about as a certbot user is what do I need to do.<p>Do I need to update certbot in all my servers? Or would they continue to work without the need to update?

The poor vendor folk needs to come more often on site to fix the cert issue.

Good.<p>If you can&#x27;t make this happen, don&#x27;t use WebPKI and use internal PKI.

Petition to Remove members voting rights from the CABForum who have a commercial interest: <a href="https:&#x2F;&#x2F;chng.it&#x2F;WcR6t2WQd2" rel="nofollow">https:&#x2F;&#x2F;chng.it&#x2F;WcR6t2WQd2</a>

Has anyone managed to calculate the increase power usage across the entire internet this change will cause? Well, I suppose the environment can take one more for the team.

ah this is gonna piss off a few coworkers today but it&#x27;s a good move either way.

semi-related question: where is the letsencrypt workalike for s&#x2F;mime?

This sucks. I&#x27;m actually so sick of mandatory TLS. All we did was get Google Analytics and all the other spyware running “““securely””” while making it that much harder for any regular person to host anything online. This will push people even further into the arms of the walled gardens as they decide they don&#x27;t want to deal with the churn and give up.

I hate this, but I&#x27;m also glad it&#x27;s happening, because it will speed up the demise of Web PKI.<p>CAs and web PKI are a bad joke. There&#x27;s too many ways to compromise security, there&#x27;s too many ways to break otherwise-valid web sites&#x2F;apps&#x2F;connections, there&#x27;s too many organizations that can be tampered with, the whole process is too complex and bug-prone.<p>What Web PKI actually does, in a nutshell, is prove cryptographically that <i>at some point in the past</i>, there was somebody who had control of either A) an e-mail address or B) a DNS record or C) some IP space or D) some other thing, and they generated a certificate through any of these methods with one of <i>hundreds</i> of organizations. <i>OR</i> it proves that they stole the keys of such a person.<p>It doesn&#x27;t prove that who you&#x27;re communicating with <i>right now</i> is who they say they are. It only proves that it&#x27;s someone who, at <i>some point</i>, got privileged access to <i>something</i> relating to <i>a domain</i>.<p>That&#x27;s not what we actually want. What we actually want is to be assured this remote host we&#x27;re talking to now is genuine, and to keep our communication secret and safe. There are other ways to do that, that aren&#x27;t as convoluted and vulnerable as the above. We don&#x27;t have to twist ourselves into all these knots.<p>I&#x27;m hopeful changes like these will result in a gradual catastrophy which will push industry to actually adopt simpler, saner, more secure solutions. I&#x27;ve proposed one years ago but nobody cares because I&#x27;m just some guy on the internet and not a company with a big name. Nothing will change until the people with all the money and power make it happen, and they don&#x27;t give a shit.

It&#x27;s hard to express how absolutely catastrophic this is for the Internet, and how incompetent a group of people have to be to vote 25&#x2F;0 for increasing a problem that breaks the Internet for many organizations yearly by a factor of ten for zero appreciable security benefit.<p>Everyone in the CA&#x2F;B should be fired from their respective employers, and we honestly need to wholesale plan to dump PKI by 2029 if we can&#x27;t get a resolution to this.

Eff this shit. I&#x27;m getting out of sysadmin.

Oh no, Bunch of stupid bureacrats came up with another dumb idea. What a surprise!

Are the 47 days to please the current US Administration?

I&#x27;m on the SSL&#x2F;TLS team @ Cloudflare. We have great managed certificate products that folks should consider using as certificate validity periods continue to shorten.