| ▲ | qwertox 14 hours ago |
| I have now implemented a 2 week renewal interval to test the change to the 45 days, and now they come with a 6-day certificate? This is no criticism, I like what they do, but how am I supposed to do renewals? If something goes wrong, like the pipeline triggering certbot goes wrong, I won't have time to fix this. So I'd be at a two day renewal with a 4 day "debugging" window. I'm certain there are some who need this, but it's not me. Also the rationale is a bit odd: > IP address certificates must be short-lived certificates, a decision we made because IP addresses are more transient than domain names, so validating more frequently is important. Are IP addresses more transient than a domain within a 45 day window? The static IPs you get when you rent a vps, they're not transient. |
|
| ▲ | cortesoft 5 hours ago | parent | next [-] |
| > Are IP addresses more transient than a domain within a 45 day window? The static IPs you get when you rent a vps, they're not transient. They can be as transient as you want. For example, on AWS, you can release an elastic IP any time you want. So imagine I reserve an elastic IP, then get a 45 day cert for it, then release it immediately. I could repeat this a bunch of times, only renting the IP for a few minutes before releasing it. I would then have a bunch of 45 day certificates for IP addresses I don't own anymore. Those IP addresses will be assigned to other users, and you could have a cert for someone else's IP. Of course, there isn't a trivial way to exploit this, but it could still be an issue and defeats the purpose of an IP cert. |
|
| ▲ | kevincox 13 hours ago | parent | prev | next [-] |
| The short-lived requirement seems pretty reasonable for IP certs as IP addresses are often rented and may bounce between users quickly. For example if you buy a VM on a cloud provider, as soon as you release that VM or IP it may be given to another customer. Now you have a valid certificate for that IP. 6 days actually seems like a long time for this situation! |
| |
| ▲ | sgjohnson 2 hours ago | parent [-] | | Cloud providers could check the transparency lists, and if there’s a valid cert for the IP, quarantine it until the cert expires. Problem solved. | | |
| ▲ | greyface- 2 hours ago | parent [-] | | That's leaving money on the table, unless they continue to charge the previous tenant for the duration of quarantine. |
|
|
|
| ▲ | bigstrat2003 14 hours ago | parent | prev | next [-] |
| The push for shorter and shorter cert lifetimes is a really poor idea, and indicates that the people working on these initiatives have no idea how things are done in the wider world. |
| |
| ▲ | akerl_ 11 hours ago | parent | next [-] | | Which wider world? These changes are coming from the CAB forum, which includes basically every entity that ships a popular web browser and every entity that ships certificates trusted in those browsers. There are use cases for certificates that exist outside of that umbrella, but they are by definition niche. | | |
| ▲ | nottorp 10 hours ago | parent | next [-] | | >which includes basically every entity that ships a popular web browser and every entity that ships certificates trusted in those browsers. So no one that actually has to renew these certificates. Hey! How long does a root certificate from a certificate authority last? 10 to 25 years? Why don't those last 120 minutes? They're responsible for the "security" of the whole internet aren't they? | | |
| ▲ | codys 7 hours ago | parent | next [-] | | > So no one that actually has to renew these certificates. I believe google, who maintain chrome and are on the CAB, are an entity well known for hosting various websites (iirc, it's their primary source of income), and those websites do use https | |
| ▲ | cpach 9 hours ago | parent | prev | next [-] | | It’s capped to 15 years. In another comment someone linked to a document from the Chrome team. Here’s a quote that I found interesting: “In Chrome Root Program Policy 1.5, we landed changes that set a maximum ‘term-limit’ (i.e., period of inclusion) for root CA certificates included in the Chrome Root Store to 15 years. While we still prefer a more agile approach, and may again explore this in the future, we encourage CA Owners to explore how they can adopt more frequent root rotation.” https://googlechrome.github.io/chromerootprogram/moving-forw... | |
| ▲ | akerl_ 10 hours ago | parent | prev [-] | | It's almost like the threat models for CA and leaf certs are different. |
| |
| ▲ | michaelt 10 hours ago | parent | prev [-] | | About 99.99% of people and organisations are neither CAs nor Browsers. Hence they have no representation in the CAB Forum. Hardly 'by definition niche' IMHO. | | |
| ▲ | akerl_ 10 hours ago | parent [-] | | The pitch here wasn't that only a few people get a vote, it was that the people making the decisions aren't aware of how "the wider world" works. And they are, clearly. The people making Chrome/Firefox and the people running the CAs every publicly-trusted site uses are aware of what their products do, and how they are used. | | |
| ▲ | themafia 3 hours ago | parent [-] | | They're aware of the major use cases. I doubt the minority cases are even on their radar. So great for E-Commerce, not so great for anyone else. |
|
|
| |
| ▲ | alibarber 13 hours ago | parent | prev | next [-] | | Well they offer a money-back guarantee. And other providers of SSL certificates exist. | | |
| ▲ | jsheard 13 hours ago | parent [-] | | For better or worse the push down to 47-day certificates is an industry-wide thing, in a few years no provider will issue certificates for longer than that. Nobody is being forced to use 6-day certs for domains though, when the time comes Let's Encrypt will default to 47 days just like everyone else. | | |
| ▲ | hungryhobbit 11 hours ago | parent | next [-] | | And you don't think that years ago people would have said "of course you'll be able to keep your security cert for more than two months"? The people who innovate in security are failing to actually create new ways to verify things, so all that everyone else in the security industry can do to make things more secure is shorten the cert expiration. It's only logical that they'll keep doing it. | | | |
| ▲ | singpolyma3 13 hours ago | parent | prev [-] | | > Nobody is being forced to use 6-day certs for domains though Yet | | |
|
| |
| ▲ | jdsully 13 hours ago | parent | prev | next [-] | | At some point it makes sense to just let us use self signed certs. Nobody believes SSL is providing attestation anyways. | | |
| ▲ | woodruffw 12 hours ago | parent | next [-] | | What does attestation mean in this context? The point of the Web PKI is to provide consistent cryptographic identity for online resources, not necessarily trustworthy ones. (The classic problem with self-signed certs being that TOFU doesn’t scale to millions of users, particularly ones who don’t know what a certificate fingerprint is or what it means when it changes.) | |
| ▲ | vimda 13 hours ago | parent | prev | next [-] | | A lot corporate environments load their root cert and MITM you anyway | | | |
| ▲ | cpach 11 hours ago | parent | prev [-] | | Then you might as well get rid of TLS altogether. | | |
| ▲ | jdsully 11 hours ago | parent [-] | | You'd still want in transit encryption. There are other methods than centralized trust like fingerprinting to detect forgeries. | | |
| ▲ | cpach 10 hours ago | parent [-] | | Haven’t seen any such system that scales to billions of user. |
|
|
| |
| ▲ | jofla_net 13 hours ago | parent | prev | next [-] | | Rule by the few, us little people don't matter. Thing is, NOTHING, is stopping anyone from already getting short lived certs and being 'proactive' and rotating through. What it is saying is, well, we own the process so we'll make Chrome not play ball with your site anymore unless you do as we say... The CA system has cracks, that short lived certs don't fix, so meanwhile we'll make everyone as uncomfortable as possible while we rearrange deck chairs. awaiting downvotes in earnest. | |
| ▲ | Sohcahtoa82 13 hours ago | parent | prev [-] | | It's really security theater, too. Though if I may put on my tinfoil hat for a moment, I wonder if current algorithms for certificate signing have been broken by some government agency or hacker group and now they're able to generate valid certificates. But I guess if that were true, then shorter cert lives wouldn't save you. | | |
| ▲ | NoahZuniga 13 hours ago | parent | next [-] | | > broken by some government agency or hacker group Probably not. For browsers to accept this certificate it has to be logged in a certificate transparency log for anyone to see, and no such certificates have been seen to be logged. | |
| ▲ | woodruffw 12 hours ago | parent | prev | next [-] | | One of the ideas behind short-lived certificates is to put certificate lifetimes within the envelope of CRL efficacy, since CRLs themselves don’t scale well and are a significant source of operational challenges for CAs. This makes sense from a security perspective, insofar as you agree with the baseline position that revocations should always be honored in a timely manner. | |
| ▲ | vbezhenar 13 hours ago | parent | prev | next [-] | | I'm not sure it is about security. For security, CRLs and OCSP were a thing from the beginning. Short-lived certificates allow to cancel CRLs or at least reduce their size, so CA can save some expenses (I guess it's quite a bit of traffic for every client to download CRLs for entire letsencrypt). | |
| ▲ | wang_li 13 hours ago | parent | prev [-] | | My browser on my work laptop has 219 root certificates trusted. Some of those may be installed from my employer, but I suspect most of them come from MS as it's Edge on Windows 11. I see in that list things like "Swedish Government Root Authority" "Thailand National Root Certification Authority" "Staat der Nederlanden Root CA" and things like "MULTICERT Root Certification Authority" "ACCVRAUZ1". I don't think there is any reason to believe any certificate. If a government wants a cert for a given DNS they will get it, either because they directly control a trusted root CA, or because they will present a warrant to a company that wants to do business in their jurisdiction and said company will issue the cert. TLS certs should be treated much more akin to SSH host keys in the known hosts file. Browsers should record the cert the first time they see it and then warn me if it changes before it's expiration date, or some time near the expiration date. | | |
| ▲ | londons_explore 13 hours ago | parent | next [-] | | Certificate transparency effectively means that any government actually uses a false certificate on the wider web and their root cert will get revoked. Obviously you might still be victim #1 of such a scheme... But in general the CA's now aren't really trusted anymore - the real root of trust is the CT logs. | | |
| ▲ | PunchyHamster 11 hours ago | parent [-] | | > Certificate transparency effectively means that any government actually uses a false certificate on the wider web and their root cert will get revoked. the ENTIRE reason the short lifetime is used for the LE certs is that they haven't figured out how to make revoking work at scale. Now if you're on latest browser you might be fine but any and every embedded device have their root CAs updated only on software update, which means compromise of CA might easily get access to hundreds of thousands devices. | | |
| ▲ | Dylan16807 17 minutes ago | parent [-] | | > the ENTIRE reason the short lifetime is used for the LE certs is that they haven't figured out how to make revoking work at scale. And 200 is not "at scale". The list of difficulties in revoking roots is a very different list from the problem you're citing. > any and every embedded device Yes it's flawed but it's so much better than the previous nothing we had for detecting one of the too-many CAs going rogue. |
|
| |
| ▲ | jofla_net 12 hours ago | parent | prev [-] | | >> TLS certs should be treated much more akin to SSH host keys in the known hosts file. Browsers should record the cert the first time they see it and then warn me if it changes before it's expiration date, or some time near the expiration date. This is great, and actually constructive! I use, a hack i put together
http://www.jofla.net/php__/CertChecker/
to keep a list (in json) of a bunch of machines (both https and SSH) and the last fingerprints/date it sees.
Every time it runs i can see if any server has changed, just is a heads-up for any funny business.
Sure its got shortcommings, it doesnt mimmic headers and such but its a start. It would be great if browsers could all, you know, have some type of distributed protocol, ie DHT where by at least some concensus about whether this cert has been seen by me or enough peers lately. Having a ton of CAs and the ability to have any link in that chain sing for ANY site is crazy, and until you've seen examples of abuse you assume the foundations are sound. |
|
|
|
|
| ▲ | mholt 13 hours ago | parent | prev | next [-] |
| It's less about IP address transience, and more about IP address control. Rarely does the operator of a website or service control the IP address. It's to limit the CA's risk. |
|
| ▲ | Sohcahtoa82 13 hours ago | parent | prev | next [-] |
| > Are IP addresses more transient than a domain within a 45 day window? If I don't assign an EIP to my EC2 instance and shut it down, I'm nearly guaranteed to get a different IP when I start it again, even if I start it within seconds of shutdown completing. It'd be quite a challenge to use this behavior maliciously, though. You'd have to get assigned an IP that someone else was using recently, and the person using that IP would need to have also been using TLS with either an IP address certificate or with certificate verification disabled. |
| |
| ▲ | qwertox 13 hours ago | parent [-] | | Ok, though if you're in that situation, is an IP cert the correct solution? | | |
| ▲ | toast0 13 hours ago | parent [-] | | It's probably not a good solution if you're dealing with clients you control. Otoh, if you're dealing with browsers, they really like WebPKI certs, and if you're directing load to specific servers in real time, why add DNS and/or a load balancer thing in the middle? |
|
|
|
| ▲ | compumike 10 hours ago | parent | prev | next [-] |
| > If something goes wrong, like the pipeline triggering certbot goes wrong, I won't have time to fix this. So I'd be at a two day renewal with a 4 day "debugging" window. I think a pattern like that is reasonable for a 6-day cert: - renew every 2 days, and have a "4 day debugging window"
- renew every 1 day, and have a "5 day debugging window" Monitoring options: https://letsencrypt.org/docs/monitoring-options/ This makes me wonder if the scripts I published at https://heyoncall.com/blog/barebone-scripts-to-check-ssl-cer... should have the expiry thresholds defined in units of hours, instead of integer days? |
|
| ▲ | andrewaylett 6 hours ago | parent | prev | next [-] |
| You should probably be running your renewal pipeline more frequently than that: if you had let your ACME client set itself up on a single server, it would probably run every 12h for a 90-day certificate. The ACME client won't actually give you a new certificate until the old one is old enough to be worth renewing, and you have many more opportunities to notice that the pipeline isn't doing what you expect than if you only run when you expect to receive a new certificate. |
|
| ▲ | PunchyHamster 11 hours ago | parent | prev | next [-] |
| What worries me more about the push for shorter and shorter cert terms instead of making revoking that works is that if provider fails now you have very little time to switch to new one |
| |
| ▲ | jsheard 11 hours ago | parent | next [-] | | Some ACME clients can failover to another provider automatically if the primary one doesn't work, so you wouldn't necessarily need manual intervention on short notice as long as you have the foresight to set up a secondary provider. | |
| ▲ | mcpherrinm 8 hours ago | parent | prev | next [-] | | This is a two-sided solution, and one significant reason for shorter certificate lifetimes helps make revocation work better. | |
| ▲ | cpach 11 hours ago | parent | prev [-] | | People have tried. Revocation is a very hard problem to solve on this scale. |
|
|
| ▲ | alibarber 13 hours ago | parent | prev | next [-] |
| If you are doing this in a commercial context and the 4 day debugging window, or any downtime, would cause you more costs than say, buying a 1 year certificate from a commercial supplier, then that might be your answer there... |
| |
| ▲ | mxey 12 hours ago | parent [-] | | There will be no certificates longer than 45 days by any CA in browsers in a few years. |
|
|
| ▲ | charcircuit 13 hours ago | parent | prev [-] |
| >I won't have time to fix this Which should push you to automate the process. |
| |
| ▲ | buckle8017 13 hours ago | parent [-] | | He's expressly talking about broken automation. | | |
| ▲ | charcircuit 13 hours ago | parent [-] | | You can have automation to fix the broken automation. | | |
| ▲ | buckle8017 11 hours ago | parent [-] | | Are you serious? real question | | |
| ▲ | charcircuit 9 hours ago | parent [-] | | Yes, as expiration times get smaller people will increase automation and robustness to deal with it. One way to increase robustness is to automatically diagnose why something failed and try and repair it. |
|
|
|
|
