- cross-posted to:
- hackernews@lemmy.bestiver.se
- cross-posted to:
- hackernews@lemmy.bestiver.se
Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.
This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.
You must log in or # to comment.
I’m sorry but if you aren’t using automated renewals then you are not using let’s encrypt the way it’s intended to be used. You should take this as an opportunity to get that set up.
Ours is automated, but we incur downtime on the renewal because our org forbids plain http so we have to do TLS-ALPN-01. It is a short downtime. I wish let’s encrypt would just allow http challenges over https while skipping the cert validation. It’s nuts that we have to meaningfully reply over 80…
Though I also think it’s nuts that we aren’t allowed to even send a redirect over 80…
Forgive my ignorance but why would that incur a downtime?
The only way I can think of for downtime to happen if you switched certs before the new one was signed (in which case …don’t) or am I missing something?
It also strikes me as weird that LE requires 80 but does allow insecure 443 after a redirect. Why not just do/allow insecure 443 in the first place?
the TLS-ALPN-01 challenge requires a https server that implements generating a self-signed certificate on demand in response to a specific request. So we have to shut down our usual traffic forwarder and let an ACME implementation control the port for a minute or so. It’s not a long downtime, but irritatingly awkward to do and can disrupt some traffic on our site that has clients from every timezone so there’s no universal ‘3 in the morning’ time, and even then our service is used as part of other clients ‘3 in the morning’ maintenance windows… Folks can generally take a blip in the provider but don’t like that we generate a blip in those logs if they connect at just the wrong minute in a month…
As to why not support going straight to 443, don’t know why not. I know they did TLS-ALPN-01 to keep it purely as TLS extensions to stay out of the URL space of services which had value to some that liked being able to fully handle it in TLS termination which frequently is nothing but a reverse proxy and so in principle has no business messing with payload like HTTP-01 requires. However for nginx at least this is awkward as nginx doesn’t support it.
Hot take: for-profit orgs should be buying TLS certificates from the CA cartel instead of using Let’s Encrypt. Unless you’re donating to LE, and in that case it’s cool.
Frankly, another choice virtually forced by the broader IT.
If the broader IT either provides or brokers a service, we are not allowed to independently spend money and must go through them.
Fine, they will broker commercial certificates, so just do that, right? Well, to renew a certificate, we have to open a ticket and attach our csr as well as a “business justification” and our dept incurs a hundred dollar internal charge for opening that ticket at all. Then they will let it sit for a day or two until one of their techs can get to it. Then we are likely to get feedback about something like their policy changing to forbid EC keys and we must do RSA instead, or vice versa because someone changed their mind. They may email an unexpected manager for confirmation in accordance to some new review process they implemented. Then, eventually, their tech manually renews it with a provider and attaches the certificate to the ticket.
It’s pretty much a loophole that we can use let’s encrypt because they don’t charge and technically the restrictions only come in when purchasing is involved. There was a security guy raising hell that some of our sites used that “insecure” let’s encrypt and demanding standards change to explicitly ban them, but the bearaucracy to do that was insurmountable so we continue.
our org forbids plain http
is redirecting http to https also out of the question? because let’s encrypt HTTP-01 accepts http -> https redirects:
Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates.
They in fact refuse to even do a redirect… it’s monumentally stupid and I’ve repeatedly complained, but ‘security’ team says port 80 doing anything but dropping the packet or connection refused is bad…
oh my god
Can’t use DNS?
The same screwed up IT that doesn’t let us do HTTP-01 challenges also doesn’t let us do DNS except through some bs webform, and TXT records are not even vaguely in their world.
It sucks when you are stuck with a dumber broad IT organization…
Wow…
Yikes. I feel for you man.
I’ve got it setup automated on all my external domains, but trying to automate it on my internal-only domain is rather tedious since not only do I NOT want to open a port for it to confirm, but I have 2 other devices/services on the network not behind my primary reverse proxy that share the same cert.
What In need to do is setup my own custom cron that hits the hosting provider to update the DNS txt entries. Then I need to have it write and restart the services that use the cert. I’ve tried to automate this once before and it did not go so smoothly so I’ve been hesitant on wasting time to try it again… But maybe it’s time to.
What would be ideal is if I could allow it to be automated just by getting a one time dns approval and storing a local private/public key to prove to them that I’m the owner of the domain or something. Not aware of this being possible though.
Depends on which DNS service you are using, a plugin might already exist that would do it for you. e.g. I use cloudflare for DNS and certbot is able to automatically set the txt record.
For internal stuff, it may be easier to set up your own CA.
Technically my renews aren’t automated. I have a nightly cronjob that should renew certificates and restart services, but when the certificates need renewal, it always fails because it wants to open a port I’m already using in order to answer the challenge.
I hear there’s an apache module / configuration I can use, but I never got around to setting it up. So, when the cron job fails, I get an email and go run a script that stops apache, renews certs, and restarts services (including apache). I will be a bit annoying to have to do that more often, but maybe it’ll help motivate me to configure apache (or whatever) correctly.
Debian Stable
You could try using the DNS challenge instead; I find it a lot more convenient as not all my services are exposed.
While I do have some control over my DNS and can create arbitrary TXT entries, I can’t to that in an automated way easily. I’m using Gandi.net to host my DNS rather than running my own DNS sever(s).
EDIT: Gandi is listed https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438 so maybe I can automate a DNS-01 challenge without too much issue, I just have to switch away from
certbotto one of the other tools.
The usual way for me is to give certbot write access to a directory in the HTTP root, so the server can keep running.
It does have access to the HTTP root directories. But, it still can’t open port 80/443 when apache already has that port open.
EDIT: I guess my
certbot renewjust needs to be reconfigured to use a--webroot, so it doesn’t try to listen on it’s own.
While I agree for my personal use, it’s not so easy in an enterprise environment. I’m currently working to get services migrated OFF my servers that utilize public certificates to avoid the headache of manual intervention every 45 days.
While this is possible for servers and services I manage, it’s not so easy for other software stacks we have in our environment. Thankfully I don’t manage them, but I’m sure I’ll be pulled into them at some point or another to help figure out the best path forward.
The easy path is obviously a load balanced front-end to load the certificate, but many of these services are specialized and have very elaborate ways to bind certificates to services outside of IIS or Apache, which would need to trust the newly issued load balancer CA certificate every 47 days.
Yeah, this has become an issue for us at work as well.
Currently we are doing a POC for an in-house developed solution where a azure function app handles the renewal of certificates for any domain we have, both wildcard and named, and place the certificates in a key vault where services that need them can get access.
Looks to be working, so the main issue now is finding a non-US certificate provider that supports acme. EU has some but even more local there aren’t many options.
I’m using automated renewals.
But, that just means there’s a new cert file on disk. Now I have to convince a half a dozen different apps to properly reload that changed cert. That means fighting with Systemd. So Systemd has won the first few skirmishes, and I haven’t had the time or energy to counterattack. Now instead of having to manually poke at it 4x per year, it’s going to be closer to once a month. Ugh.
Half a dozen sounds like a lot, kinda curious what you are running? If they all are web services maybe use a reverse proxy or something?
Web services, and then various components of an email system.
If you have the time to set it up, Stalwart can manage its own cert renewal.
I don’t want to have to completely redo my whole email stack.
Which is fair enough
Don’t worry, they’ll sell you new software for another $50.00/m/certificate to help with the new certificate fiddling you now have to do monthly. It didn’t make sense for them to release it until they pushed through the 45 day window change through backchannels.
You could try a path unit watching the cert directory (there are caveats around watching the symlinks directly) or most acme implementations have post renewal hooks you can use which would be more reliable.
So what’s the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1? Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
It is ignoring the elephant in the room – the central root CA system. What if that is ever compromised?
Certificate pinning was a good idea IMO, giving end-users control over trust without these top-down mandated cert update schedules. Don’t get me wrong, LetsEncrypt has done and is doing a great service within the current infrastructure we have, but …
I kind of wish we could just partition the entire internet into the current “commercial public internet” and a new (old, redux) “hobbyist private internet” where we didn’t have to assume every single god-damned connection was a hostile entity. I miss the comraderie, the shared vibe, the trust. Yeah I’m old.
So what’s the floor here realistically, are they going to lower it to 30 days, then 14, then 2, then 1?
LE is beta-testing a 7-day validity, IIRC.
Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
No, those are expected or even required to be automated.
7-day validity is great because they’re exempt from OCSP and CRL. Let’s Encrypt is actually trying 6-day validity, not 7: https://letsencrypt.org/2025/01/16/6-day-and-ip-certs
Another feature Let’s Encrypt is adding along with this is IP certificates, where you can add an IP address as an alternate name for a certificate.
Ah, well. I only remembered something about a week.
Will we need to log in every morning and expect to refresh every damn site cert we connect to soon?
Certbot’s default timer checks twice a day if it’s old enough to be be due for a renewal… So a change from 90 to 1 day will in practice make no difference already…
Good point. On that note I am very happy having moved my home server from Apache to Caddy. The auto cert config is very nice.
The current plan is for the floor to be 47 days. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days, and this is not until 2029 in order to give people sufficient time to adjust. Of course, individual certificate authorities can choose to have lower validity periods than 47 days if they want to.
Essentially, the goal is for everyone to automatically renew the certificates once per month, but include some buffer time in case of issues.
Is this the same trust that would infect a box in under a minute if not behind a router?
The same trust of needing to scan anything you downloaded for script kiddie grade backdoors?
Zero click ActiveX / js exploits?
Man I’m probably the same age and those are some intense rose colored glasses 😅
Oh, definitely rose-coloured, but I am thinking even before those days… like when access to Usenet was restricted to colleges and universities, dial-up BBSes … and I didn’t use Windows or MacOS at all back then. ActiveX and js didn’t even exist back then. Boot-sector floppy viruses did, but those were easy to guard against.
Ah yeah, those were interesting times. (Although there were some historically interesting viruses back in the day for those floppies too)
Fond memories though. Learning basic on a cartridge… Using literal cassettes for storage. That horrifying sound of a 5" floppy drive struggling to read that file you really needed. Good times.
Generally speaking that was probably what most of us would identify as pre internet times - but usenet / BBS / and early internet and prior definitely was more bright eyed and optimistic. Probably because it was more about learning and tech and less about monotizing every square inch of your existence 😂
The best approach for securing our CA system is the “certificate transparency log”. All issued certificates must be stored in separate, public location. Browsers do not accept certificates that are not there.
This makes it impossible for malicious actors to silently create certificates. They would leave traces.
Isn’t this just CRL in reverse? And CRL sucks or we wouldn’t be having this discussion. Part of the point of cryptographically signing a cert is so you don’t have to do this if you trust the issuer.
Cryptography already makes it infeasible for a malicious actor to create a fake cert. The much more common attack vector is having a legitimate cert’s private key compromised.
No, these are completely separate issues.
- CRL: protect against certificates that have their private key compromised
- CT: protect against incompetent or malicious Certificate Authorities.
This is just one example why we have certificate transparency. Revocation wouldn’t be useful if it isn’t even known which certificates need revocation.
The National Informatics Centre (NIC) of India, a subordinate CA of the Indian Controller of Certifying Authorities (India CCA), issues rogue certificates for Google and Yahoo domains. NIC claims that their issuance process was compromised and that only four certificates were misissued. However, Google is aware of misissued certificates not reported by NIC, so it can only be assumed that the scope of the breach is unknown.
Or the more likely a rouge certificate authority giving out certs it shouldn’t.
This seems like a good idea.
The only disadvantage I see is that all my personal subdomains (e.g. immich.name.com and jellyfin) are forever stored in a public location. I wouldn’t call it a privacy nightmare, yet it isn’t optimal.
There are two workarounds:
- do not use public certificates
- use wildcard certificates only
But how to automate wildcard certificate generation? That requires a change of the txt record and namecheap for instance got no mechanism for that to automatically happen on cert bot action
There are some nameserver providers that have an API.
When you register a domain, you can choose which nameserver you like. There are nameservers that work with certbot, choose one that does.
Namecheap supports this according to docs. I just haven’t tested yet.
Doesn’t caddy support that (name cheap txt mod) via a plug-in?
I haven’t tried it yet, but the plugin made it sound possible. I’m planning to automate on next expiration… When I get to it ;)
I did already compile caddy with the plugin, just haven’t generated my name cheap token and tested.
“when i get to it” is my time frame aswell, till then its a reoccurring calendar notification with instructions because past me who set this all up was a genius compared to sleep deprived current me
I definitely know that feeling.
Now that I’m at a keyboard, here’s the (Caddy) plugin I was referring to : https://github.com/caddy-dns/namecheap
You can already get 6-day certificates if you want to https://letsencrypt.org/2025/01/16/6-day-and-ip-certs
where we didn’t have to assume every single god-damned connection was a hostile entity
But you always did, it was always being abused, regularly. That’s WHY we now use secure connections.
I think I’m just not picking up whether you’re actually trying to pitch a technical solution, or just wishing for a perfect world without crime.
More the latter :) … if only we could all just get along and be nicer to each other. Sigh.
Fair enough lol, can’t argue with that.
Not exactly what you mean because there are also bad actors but take a look at i2p, in some ways it feels like an retro internet.
Seeing as most root CA are stored offline compromising a server turned off is not really possible.
I’m more annoyed that I have 10 year old gear that doesn’t have automation for this.
Oh, I’m really just pining for the days before the ‘Eternal September’, I suppose. We can’t go back, I know. :/
Signing (intermediate) certs have been compromised before. That means a bad actor can issue fake certs that are validated up to your root ca certs
While you can invalidate that signing cert, without useful and ubiquitous revocation lists, there’s nothing you can do to propagate that.
A compromised signing certs, effectively means invalidating the ca cert, to limit the damage
I still think the web would have been better off if certificates were signed and part of a web of trust like in GPG/PGP. It wouldn’t stop sites from using trusted CAs to increase their trust levels with browsers, but it would mean that tiny websites wouldn’t need to go through layers of mandatory bullshit and inconvenience. Also means that key signers could have meaningful business relationships rather than being some random CA that nobody has a clue about.
3 letter organisms: NSA - CIA. People tend to think that’s a conspiracy theory… Even though we have so many real life examples about how the US and the 3 letters agencies have their hands all over the web and privacy and encryption is just a wet dream !
It’s the “change your password often odyssey” 2.0. If it is safe, it is safe, it doesn’t become unsafe after an arbitrary period of time (if the admin takes care and revokes compromised certs). If it is unsafe by design, the design flaw should be fixed, no?
Or am I missing the point?
The point is, if the certificate gets stolen, there’s no GOOD mechanism for marking it bad.
If your password gets stolen, only two entities need to be told it’s invalid. You and the website the password is for.
If an SSL certificate is stolen, everyone who would potentially use the website need to know, and they need to know before they try to contact the website. SSL certificate revocation is a very difficult communication problem, and it’s mostly ignored by browsers because of the major performance issues it brings having to double check SSL certs with a third party.
The point is, if the certificate gets stolen, there’s no GOOD mechanism for marking it bad.
That’s what OCSP is for. Only Google isn’t playing along as per that wiki entry.
I mean, are you intending to retroactively add SSL to every tool implementing SSL in the past few decades?…
Browsers aren’t the only thing that ingress SSL.
Then there’s the older way of checking CRLs which any tool of the past few decades should support.
That’s what Carla are for.
How did you reply to a deleted comment?
Probably the comment has federated to lemmy.world, but the deletion of the comment hasn’t yet.
Looks like autoincorrect did a s/CRLs/Carla/ for you.
And that somehow Lemmy didn’t federate my deletion!
But browsers have a marker for dangerous sites - surely Cloudflare, Amazon or Google should have a report system and deliver warnings at the base
Browsers are only a (large) fraction of SSL traffic.
So is there an example of SSL certs being stolen and used nefariously. Only thing that sticks out to me is certificate authorities being bad.
Yep. https://fedia.io/m/selfhosted@lemmy.world/t/3090624/Decreasing-Certificate-Lifetimes-to-45-Days/comment/13237364#entry-comment-13237364
Short lifespans are also great when domains change their owner. With a 3 year lifespan, the old owner could possibly still read traffic for a few more years.
When the lifespan ist just 30-90 days, that risk is significatly reduced.
Only matters for LE certs.
You can still buy 1 year certsFor 3 more months or so, you can’t buy them in april 2026 anymore
oh? Damn
They are going down to 200 day expiration in March 2026. You can still buy 5 year certificates today but you still need to reissue them in 365 day cadence.
Moot point!
You could still get certificates for other people’s domains from Honest Ahmed 's used cars and totally trustworthy CA or so. But that’s another story. (there are A LOT of trusted CAs in everybody OS and browser. Do you know and trust them all?)
The maintainers of the big web browsers have pretty strict rules for CAs in this list. If any one of them gets caught issuing only one certificate maliciously, they are out of business.
And all CAs are required to publish each certificate in multiple public, cryptographically signed ledgers.
Sure, there is a history of CAs issuing certificates to people that shouldn’t have them (e.g. for espionage), but that is almost impossible now.
minor panic, oh, “2028”.
Might as well adjust the setting now. I had that same feeling for something they changed several years ago and never got around to changing it til all my stuff went down lol.
yeah good advice
Reducing the validity timespan will not solve the problem, it only reduces the risk. And how big is that risk really? I’m an amateur and would love to see some real malicious case descriptions that would have been avoided had the certificate been revoked earlier…
Anybody have some pointers?
Terminology: revoked means the issuer of the certificate has decided that the certificate should not be trusted anymore even though it is still valid.
If a attacker gets access to a certificates key, they can impersonate the server until the validity period of the cert runs out or it is revoked by the CA. However … revocation doesn’t work. The revocation lists arent checked by most clients so a stolen cert will be accepted potentially for a very long time.
The second argument for shorter certs is adoption of new technology so certs with bad cryptographic algorithms are circled out quicker.
And third argument is: if the validity is so short you don’t want to change the certs manually and automate the process, you can never forget and let your certs expire.
We will probably get to a point of single day certs or even one cert per connection eventually and every step will be saver than before (until we get to single use certs which will probably fuck over privacy)
No, but I have a link showing how ISPs and CAs colluded to do a MITM https://notes.valdikss.org.ru/jabber.ru-mitm/
Shorter cert lifespan would not prevent this.
It really just helps in cases where you get hacked, but the hacker doesn’t have continued access. Say someone physically penetrates into your building, grabs the key through an unlocked station, and leaves.
That being said, like you mentioned, if someone is going through this effort, 45 days vs 90 days likely won’t matter. They’ll probably have the data they need after a week anyways.
Encryption key theft really requires a secondary attack afterwards to get the encrypted data by getting into the middle and either decrypting or redirecting traffic. It’s very much a state level/high-corporate attack, not some random group trying to make a few bucks.
I’ve been dreading this switch for months (I still am, but I have been, too!) considering this year and next year will each double the amount of cert work my team has to do. But, I’m hopeful that the automation work I’m doing will pay off in the long run.
Are you not using LE certbot to handle renewals? I can’t even imagine doing this manually.
Personally, yes. Everything is behind NPM and SSL cert management is handled by certbot.
Professionally? LOL NO. Shit is manual and usually regulated to overnight staff. Been working on getting to the point it is automated though, but too many bespoke apps for anyone to have cared enough to automate the process before me.
One reason for the short certs is to push faster adoption of new technology. Yes that’s about new cryptography in the certs but if you still change all your certs by hand maybe you need to be forced …
I’m in the same boat here. I keep sounding the alarm and am making moves so that MY systems won’t be impacted, but it’s not holding water with the other people I work with and the systems they manage. I’m torn between manual intervention to get it started or just letting them deal with it themselves once we hit 45 day renewal periods.
Luckily I am using only traefik and everything goes through it that it needs for.
Can’t imagine how annoying it would be to interface with every equipment so there are no https errors…
YES! Keep cutting it down!
Revocation is a lost cause and if you don’t automate you deserve what you get.
I have multiple self hosted services at home which are impossible to automate because they are not accessible from the internet without VPN. And some even don’t have internet access. Still me and my roommates are using them through a valid domain that points to the local address enabling https. Some services require https to function at all. After log4j i’ll never again open a “normal” port 80 or 443 to my local net. So thanks i guess. 90 days was annoying already. Great it works out for you
Use DNS validation
The solution is to not use Http based validation of the cert, but use dns based validation. Possibly combined with a wildcard cert for your whole domain. This is what I do for internal services on my LAN, along with split DNS so that the internal services aren’t even listed in public DNS.
Dude, you need to figure out a way to automate that. It’s no way to live.
I agree, but it’s impossible to convince my less tech savy roommates and friends to let me install a root certificate. “That sounds like i could read all their private messages”, lol. Just let me have my certificate for https in my local net. I don’t need to be “even more” secure. I get that that’s necessary for public services, but surely not for local selfhosting. I don’t even have a port open other than wireguard. And i would not even care “if a roommate hacks/gets access to a guests voice commands for home assistant.” (Not complaining at you but at this trend. I do think my use case is valid)
You are gonna laugh if i tell you how i partly automated this workaround. A script changes the (dyn) dns entries of all subdomains to point to my public server in a datacenter. There, it ssh’s in and requests the certificates with certbot. Then, it restores the dns entries and downloads and installs the certificates in the local net. Still requires manual supervision and sometimes intervention. My domains do not support automated dnssec. I don’t have time to secure my local net enough to feel good about opening ports. If all certificate lifetimes get shorter, i’ll either have to switch my domain provider or give up selfhosting for other people.
Allowing a certificate without proper validation for local only networks is a terrible, terrible idea. I could super easily use this as a loophole to set up a honeypot public free wi-fi, redirect all traffic through a reverse proxy and man-in-the-middle every single HTTPS connection, effectively allowing me to harvest everyone’s passwords in a really quick and easy way.
Just use DNS verification. It’s not that hard.
I’ve had dns-01 validation running for a while now. It’s not difficult, just a paradigm shift. I spent a minute just now looking for a concise how-to for you and didn’t find one, so I suppose I’ll have to write it.
I’ll bookmark this comment so I can find you once I’ve done that.
deleted by creator
I’m trying to think of the last time I heard news about something to do with the internet getting better instead of worse, and I’m genuinely coming up blank.
Make no mistake: this is an improvement.
There are substantial unsolvable issues with long lived certificates, and automatic deployment of very short lived certificates is the way to solve them.
Plan for certificate validity of six days in a few years.
Wait, how’s this worse? This makes the Internet safer by reducing the window a leaked key can do harm.
Automated certificates are relatively new and pretty neat. Killing off the certificate cartels is an added bonus.
Yeah, I think Letsencrypt (and others) are one of the best things to happen for the internet.
You used to have to cough up a good chunk of monies for a certificate.
Now it’s easily accessible and you (i) never have to think about it after the first setup because a robot automatically renews expiring certificates for me.
Generally this is one of the best improvements: a more secure web that is easier to achieve.
As some selfhosting novice who uses NPM with auto renewal - I feel that I shouln’t be ocncerned.
Check your autorenewal failure alerts go somewhere you’ll react to.
Reducing the valid time will not solve the underlying problems they are trying to fix.
We’re just gonna see more and more mass outages over time especially if this reduces to an uncomfortably short duration. Imagine what might happen if a mass crowdflare/microsoft/amazon/google outage that goes on perhaps a week or two? what if the CAs we use go down longer than the expiration period?
Sure, the current goal is to move everybody over to ACME but now that’s yet another piece of software that has to be monitored, may have flaws or exploits, may not always run as expected… and has dozens of variations with dependencies and libraries that will have various levels of security of their own and potentially more vulnerabilities.
I don’t have the solution, I just don’t see this as fixing anything. What’s the replacement?
clearly the most secure option is to have certificates that are only valid for 30 seconds at a time
Let’s be extra safe. New cert per every request
Ephemeral diffie-hellman is exactly that, it’s part of TLS since I think 1.2
Well it should be as short as possible while still being practical. LE doesn’t have infinite server compute, renewal also takes some amount of time, plus if they make the validity too short people might stop using them (pretty evident judging from sentiment here) and move to other CAs and make what they do pointless.
45 days are still plenty of time yet people are already complaining. Does make me worry.
assuming “rest of the industry” in this context refers to ssl seller lobby.
Yes, this requirement comes from the CA/Browser Forum, which is a group consisting of all the major certificate authorities (like DigiCert, Comodo/Sectigo, Let’s Encrypt, GlobalSign, etc) plus all the major browser vendors (Mozilla, Google, and Apple). Changes go through a voting process.
Google originally proposed 90 day validity, but Apple later proposed 47 days and they agreed to move forward with that proposal.
Don’t worry they’ll reduce the cost of certificates proportionally to the longevity of the certificate.
Right? Anybody?
<< Cricket noises >>
Edit: obviously not LE, but other certificate vendors.
DigiCert have said they’re not changing their prices as a result. It’s still a yearly payment (or every 2 or 3 years if you prefer that).
Lol, never had to buy a cert huh?
You’re still buying a year or more at a time, no matter the lifetime of the cert itself. Even if the cert lifetime was a week, you’re still buying the same product, no matter how many times you rotate it.
Personally? No I’ve never bought a cert before. Given there’s free alternatives and it’s a homelab it doesn’t make sense. Otherwise I’ve used them on AWS, where ACM also just provides them for free.
What you’re saying is that certificate providers will still charge you and provide certificates for a year, but just provide you with N certificates to span that year?
E.g. if the duration is 45 days then they will give you 365/45 certificates ?
. if the duration is 45 days then they will give you 365/45 certificates ?
Minimum. We get through digicert at work, and we abuse the hell out of our wildcard and reissue it tons of times a year. You’re buying a service for the year, not an individual cert.
Interesting. Thanks for that insight :)
Coming soon. Daily certs. Just $19.99 a month.
Just skip to the point and make it 1 day
the whole point is to not break the internet. slow is fine
Just let me know so I can change my crontabs.
