Pros and cons of 90-day certificate lifetimes

I think you are missing something. changine cets quickly and HPKP can be a problem, because HPKP has an enforce lifetime. but with DANE/TLSA you can change the cert/key information anytime in the DNS and when you dont set the lifetime too high and have a nice way of auto-changing your DNS (cloudflare api might work as example) then you yould even use 1-day certs with dane. also when you use dane in TAA mode (trust anchor assertion, aka “make your own CA”) you can just specify your favored root and make as many leaf certs as you want without touching the DNSSec.

3 Likes

DNSSEC/TLSA also has a TTL (you have to carefully respect them in the same way as the HPKP lifetime; for the very same reason DANE alone won’t be the only solution for the future as during the TTL cache time the old certificate is still valid and cannot be revoked as with an PKI - ok, here an attacker could also “cache” a valid OCSP request for 2 days…), TAA mode does not work as not browser implements it right now OR just trust Let’s Encrypt CA and don’t win anything as it is not pinned to your own certificate.

2 Likes

well yeah browser need to Implement TAA, but when implementing dane, TAA could be done as well...
also I did say

in cloudflare the life of your records as be as low as 2 minutes while with HPKP the lifetime should be as long as possible because HPKP isnt really through another connection.

2 Likes

This gets off-topic again as I already mentioned DNSSEC/TLSA…

But: not everyone uses cloudflare and btw. if I would use cloudflare, then I could just drop DNSSEC and SSL/TLS at all, as cloudflare can manipulate DNS and therefore potentially read everything (even if you don’t use their ssl mitm, they can just use arbritrary dns answers and make visitors use their ssl mitm even if you don’t like it)… - It’s not under my control, it’s under cloudflare’s control (or, if you trust cloudflare, anyone who has my cloudflare password). Besides that: 2 minutes are 2 possible minutes with validation errors in case of a certificate update… (If someone is realy serious about security, then even DNSSEC/TLSA is not really safe, as the chain of trust is not really there, as you don’t directly give your keys to the registry, but to your domain-hoster - and if there is a break, then evil people can send arbritrary new keys to the registry…)

2 Likes

you dont have to use cloudflare as mitm I just use it as DNS and make the clouds grey, aka dont use the cdn.

3 Likes

This is clearly an off-topic sub-discussion now:
If cloudflare manages my dns, Cloudflare could still manipulate DNS and mitm my webpage (or even catch my mail)…

2 Likes

Yes, the DNSSEC discussion is indeed off-topic. Reminder: you can use “Reply as linked topic” if there’s something you’d like to discuss on a separate thread. Thanks!

5 Likes

on mail client side, when we change/renew SSL, user need to accept new certificate. Even once in a year, I always have too many people asking if they can just accept that pop up.

just curious : when LE will renew the SSL? on the day of expired time of we can force to renew few day earlier? If something happen on renewal date (DDoS, etc) we will left without services :frowning:

2 Likes

karo, according to the documentation published, you should renew about 30 days before expiration, which is 60 days after issuance. There is no current stable automatic process with the official client, so you’d run the process manually.

Maybe it’s a specific client, but I haven’t seen any popups for mail clients as long as the certificate is signed by a trusted CA and you connect to the name that is specified on the certificate.

3 Likes

Let's Encrypt certificates currently have a ninety-day lifetime9. Web standards do not require any minimum certificate lifetime. As of 2015, the Baseline Requirements3 specify a maximum certificate lifetime of 39 months.

The Technical Advisory Board5, chose a 90-day certificate lifetime to start with, with an expectation that people will want to auto-renew at the 60-day mark.

30 days is often used to keep CRLs small for mobile clients. That's why Google rotates the certificates on its properties every 30 days. However, they re-certify the same public key.

Otherwise, it can create a DoS for user agents over wireless. From Peter Gutmann's Engineering Security, page 640:

... For PKIs sized at tens of thousands of users, multi-megabyte CRLs are not uncommon, and the potential size of CRLs for hypothesised national CAs/PKIs is unpleasant to contemplate. As long ago as 1998 a Verisign employee had warned that for user populations much larger than 10,000 certificates the use of CRLs “requires infrastructure capabilities that are beyond the state of the art and further may not operate in practice” [214] (in practice if the CRLs are issued extremely infrequently and most clients don’t check them then this can be made to appear to work, for some value of “work”).

An example of these problems was illustrated by the Johnson and Johnson PKI which, with 60,000 users, had a CRL over a megabyte in size after its first year of operation [215], requiring that users fetch roughly a million times more data than necessary for any certificate check (the entire CRL had to be fetched in order to obtain the effect of a single boolean valid/not valid flag). The problem was “solved” in this instance by only issuing a CRL once a week and caching old copies of the CRL to turn it into the ritual check described earlier, a relatively common approach whenever this problem raises its head. In contrast the rather larger US Department of Defence (DoD) PKI, which by 2005 had issued sixteen million certificates and revoked ten million of those, was issuing fifty megabyte CRLs (!!) that users had to download once a day [216]. A few years later these had grown to over a hundred megabytes, with the largest CRL known to the author, reportedly from a European government CA, being over 150MB, resulting in what’s euphemistically reported as “low user satisfaction” as systems appear to hang while they retrieve and search such monstrous CRLs [217].

A kludge adopted by one organisation to try and address this problem was to start removing fields from the CRL in an attempt to reduce its size, discarding accuracy in the interests of just getting some sort of data out the door [218]. Another CA, even after taking this drastic step in addition to splitting the load across four sub-CAs, still ended up with 90MB CRLs, with widely-used tools requiring around a gigabyte of memory to process one of these monster CRLs [219]. Other PKIs went even further, using dozens and dozens of CAs (with their attendant cost and overhead) purely to restrict the size of the CRL that any one CA had to issue. The reason for the rapid growth of these CRLs is that great quantities of certificates are routinely revoked for benign purposes entirely unanticipated by the X.509 designers, discussed in more detail in “Case Study: Inability to Connect to a Required Server” on page 502.

Maybe let's Encrypt should issue certificates for 45 day, and send a new certificate every 30 days, without requiring a re-enrollment. At 90 days or 180 days, it could require operators to prove possession of the private key again.

And a 90-day or 180-day (or longer) certificate could be an upsell item to help defer costs.

5 Likes

I think there’s an extremely strong argument missing from the above list for longer certificate lifespans.

If the goal is truly to get people to “encrypt” nobody wants to login to multiple servers and update certs every 3 months. This will be the single biggest deterrent there is to getting people to embrace https and undermines the fundamental mission of LetsEncrypt.

If you go to any other certificate authority the industry standard is one year, and often they try to up-sell you to 2 or 3 years. I understand there are some security concerns with this (from the above list) but please let the end user make their own decision.

On a personal and emotional note- this seems wayyyy overly controlling to me, almost like a “father knows best” mentality.

15 Likes

The prior issue has been the costs by the hosting company since SNI wasn't widely supported. That should be much relieved now, but many legacy hosters will still want to charge for "SSL" to keep the profits or because they or their software doesn't support SNI (and unique IPv4 are often a recurring cost from the datacenter).

That is a much larger deterrent than a quarterly renewal requirement. Also, the goal is to make renewal automated, which should relieve that burden over time.

That's because they want your money.

To a degree, it is. However, with shorter lifespans, it helps reduce the impact of Let's Encrypt certificates should something like Heartbleed or the Debian SSLKeys weak keys issue happen again. Likewise, it would also help speed things like the transition to SHA256 signatures.

I'm personally in favor of an optional 1 year maximum lifespan for those people that want a longer cert expiration, but nothing longer.

3 Likes

This makes perfect sense, but it is prohibited by the Baseline Requirements. From V1.3.1, 4.9.10. On‐line Revocation Checking Requirements:

For the status of Subscriber Certificates:
The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.

I believe several root programs adjust these limits downward, so the actual limits may be shorter.

4 Likes

Here are 2 concerns I have with the auto-renew plan.

  1. When you are hardening a server it’s best practices to NOT have a bunch of developer tools and compilers installed on that server. This aids attackers in being able to compile privilege escalation exploits etc. As I understand it the current strategy for renewing certs would require me to have python installed to run letsencrypt-auto. So any security advantage I’m gaining from Heartbleed like flaws I am losing because I have to keep python installed on the system.

  2. I had to change my firewall rules to allow port 80 into my server. By default I disable port 80 and only allow in 443. The current renewal process requires verification on port 80 which would mean I’d have to keep port 80 open all the time which is again against best security practices.

If I could somehow renew without compromising security on #1 and #2 above I’d be on board with the auto-renew plan. But until those concerns are alleviated I prefer keeping things simple and allowing longer certificate lifetimes.

7 Likes

A lot of system tools on Linux are written in Python, so you'd lose a lot of functionality by not having Python itself installed.

You could use a script or other tool to open the port before the validation and then remove the rule after it's complete.

The protocol used, ACME, is a documented system, so it wouldn't be too difficult to write your own tool, or for someone else to write a tool that would be compiled code to do the steps you want. I personally prefer to think of the official client as a reference implementation.

4 Likes

The pros I see from LE 90 day certs are that commercial CAs will likely reduce prices on their DV certs. They may even go with free renewable 90 day or cheaper 1 yr. Both are wins for the internet as a whole.

On a side note, I am getting the impression that some on here think LetsEncrypt is trying to be a one-size-fits-all CA. I do not recall anyone saying anything remotely similar to that. There are a huge number of situations/configurations where LE will not and maybe should not be applied.

By limiting the certs to 90 days and the capability to automate, LE can fit into the largest number of servers where encryption, at its current price/cost would virtually guarantee no encryption would be implemented.

If it is too much hassle to deal with 90 certs on a particular configuration then I suspect the cost of a commercial cert (ie wildcard) is a minimal concern.

6 Likes

It seems like you have a long list of objections with Let’s Encrypt. Why not just use an SSL from a commercial CA if: you dont like Let’s Encrypt’s 90 day renewal period, you dont like their automation plan, and you dont think the security risks of the client are acceptable?

Single domain certificates are available from Comodo for ~$10 a year. They offer multi-domains which are only a few dollars per SAN.

4 Likes

Indeed, folks need to decide what's best for them. For instance, I am only going to use letsencrypt ssl certs for small sites in terms of subdomain usage. I will still use SSL wildcard for some domains, as it's alot easier when you have 90+ subdomains hanging off a single domain and at a whim I can spin up other subdomains for testing on my Centmin Mod LEMP stack installer. I also have automated my SSL wildcard deployment to Nginx vhost sites I auto generate too. SSL wildcards are best weighing up my time at less US$40/yr so 90+ subdomains/domain = 40/90 = US$0.444 per domain!

Right tool for the right job folks !

3 Likes

You have misunderstood. I AGREE with LE stance on 90 day certs. I do not run a complex config so it works well for me. While I personally do not care for automating the script AT THIS TIME, the option for it in the future is appealing. I also see the latent security benefits as well. Potential vulnerablities would be far easier to mitigate when a cert expires before a hacker can get around to your site. Granted, my interest is more of a personal/family nature. I tested with a self-signed but as my family members (wife and mother in law) are completely clueless and I did not want them to get into the habit of casually clicking buttons.

For me, Lets Encrypt is a perfect fit.

3 Likes

I think you have misunderstood :smile:

My post was a reply to raairb, not you. You can see this icon in the top right of a post when its a reply to another post:

2 Likes