I still don’t see any value to this. I have not seen any data which suggests there were many situations where the 90 day certificate presented a security hole that a 6 day certificate would fix. It seems like yet another pointless security theater step everyone will need to follow in order to get the “top scores” on security scans that mean nothing but matter a lot to insurers and auditors.
I think Let’s Encrypt solved the problem they set out to solve, they are looking to switch to 6 day certificates so there is a justification to grow. From their 2024 Annual Report:
We,
on the other hand, are going to have to think about the possibility that we will need to issue
20x as many certificates as we do now. It’s not inconceivable that at some point in our next
decade we may need to be prepared to issue 100,000,000 certificates per day
My bet is from a practical security perspective there is no measurable difference between 90 days and 6 days in terms of actual exploits from these certificates. I would also bet there would be almost none if they went from 90 days to 180 days. This is entirely about having some reason to go back to their donors and have some justifiable reason for them to increase their donation and has nothing to do with actual “security”.
Yeah, I’m conflicted. I think more-temporary keys is cool and all, and I’ve got nothing against automating renewals, but
Our six-day certificates will not include OCSP or CRL URLs.
How is that better ? I’m not real sure I’d rather have an unrevocable(?) 6-day cert over a “normal” 90+-day cert. If the assumption is that the cert will get stolen, do we just .. not care what they do with it in those 6 days? I’m not as bright as I used to be; I guess I’m missing something.
IP Address certificates! At last! I have wanted it since I deployed DNS-over-TLS in 2018. I wonder why it is coupled to short lifetimes … I suppose it’s relatively rare these days to have a service running on the same IP addresses for 25 years.
Call me (something like) a cynic, but I think they’re offering IP Address certificates in conjunction with their 6-day certificates to increase the appeal of opting into short certificate lifetimes.
Though, that said, I kind of think a short lifetime should be a prerequisite to offering IP address certificates to the public (as opposed to on internal PKIs). The main reason, IMO, is that there is no natural unit of IP address assignment to an entity the size of a server operator. Domain names expire. You can look up when they expire. If you’re deciding to issue a certificate for a domain name, and the domain registration expires in 40 days, you can limit your lifetime to that even if you’d normally issue certs that are valid for 90, 120, 365, etc. days. There’s no such external record for who controls an IP address.
Having spent too much time over the years working on certificate validation and revocation, my current belief is that, especially in the context of the web pki, revocation isn’t real if you need it as a security property. There is only expiration. So I agree with LetsEncrypt that shorter validity periods are good overall, and that goes double when you can’t determine what validity “should” be.
I bet it’s because they (correctly or not) think that the majority (or a good chunk) will want this for spot cloud instances. I mean, I have no numbers but my gut feeling says the more automated your org’s operations, the quicker turnover you have for IPs and some are measuring allocations more in hours than months, with most people being “between 2 deploys”, so probably days to weeks.
this new blog post has a lot more detail, and that old blog post doesn’t even mention IP address certificates, so I don’t think they are dupes. and since it’s been more than a month, I don’t think the stories should be merged.
Are there any limitations to TLS over IP in practice? That would be awesome in certain automation situations where because it would avoid a manual step of getting a domain name without losing security.
Not for https as far as I know. I think some clients might have implementation edge cases that the community will only learn through this kind of large scale.
I still don’t see any value to this. I have not seen any data which suggests there were many situations where the 90 day certificate presented a security hole that a 6 day certificate would fix. It seems like yet another pointless security theater step everyone will need to follow in order to get the “top scores” on security scans that mean nothing but matter a lot to insurers and auditors.
I think Let’s Encrypt solved the problem they set out to solve, they are looking to switch to 6 day certificates so there is a justification to grow. From their 2024 Annual Report:
My bet is from a practical security perspective there is no measurable difference between 90 days and 6 days in terms of actual exploits from these certificates. I would also bet there would be almost none if they went from 90 days to 180 days. This is entirely about having some reason to go back to their donors and have some justifiable reason for them to increase their donation and has nothing to do with actual “security”.
Yeah, I’m conflicted. I think more-temporary keys is cool and all, and I’ve got nothing against automating renewals, but
How is that better ? I’m not real sure I’d rather have an unrevocable(?) 6-day cert over a “normal” 90+-day cert. If the assumption is that the cert will get stolen, do we just .. not care what they do with it in those 6 days? I’m not as bright as I used to be; I guess I’m missing something.
IP Address certificates! At last! I have wanted it since I deployed DNS-over-TLS in 2018. I wonder why it is coupled to short lifetimes … I suppose it’s relatively rare these days to have a service running on the same IP addresses for 25 years.
Call me (something like) a cynic, but I think they’re offering IP Address certificates in conjunction with their 6-day certificates to increase the appeal of opting into short certificate lifetimes.
Though, that said, I kind of think a short lifetime should be a prerequisite to offering IP address certificates to the public (as opposed to on internal PKIs). The main reason, IMO, is that there is no natural unit of IP address assignment to an entity the size of a server operator. Domain names expire. You can look up when they expire. If you’re deciding to issue a certificate for a domain name, and the domain registration expires in 40 days, you can limit your lifetime to that even if you’d normally issue certs that are valid for 90, 120, 365, etc. days. There’s no such external record for who controls an IP address.
Having spent too much time over the years working on certificate validation and revocation, my current belief is that, especially in the context of the web pki, revocation isn’t real if you need it as a security property. There is only expiration. So I agree with LetsEncrypt that shorter validity periods are good overall, and that goes double when you can’t determine what validity “should” be.
Or even 90 days? I think it’s a good idea to test with lower lifetimes. Gives them deployment feedback for both features at once.
I bet it’s because they (correctly or not) think that the majority (or a good chunk) will want this for spot cloud instances. I mean, I have no numbers but my gut feeling says the more automated your org’s operations, the quicker turnover you have for IPs and some are measuring allocations more in hours than months, with most people being “between 2 deploys”, so probably days to weeks.
Meanwhile Qualsys has a “vulnerability scanner” that says a certificate that expires in under a month is a level 1 vulnerability(38174): https://docs.qualys.com/en/certview/latest/get_started/certview_qids.htm
Dupe https://lobste.rs/s/nnuufh/let_s_encrypt_will_begin_offering_6_day
this new blog post has a lot more detail, and that old blog post doesn’t even mention IP address certificates, so I don’t think they are dupes. and since it’s been more than a month, I don’t think the stories should be merged.
Are there any limitations to TLS over IP in practice? That would be awesome in certain automation situations where because it would avoid a manual step of getting a domain name without losing security.
Not for https as far as I know. I think some clients might have implementation edge cases that the community will only learn through this kind of large scale.