Pros and cons of 90-day certificate lifetimes

If I’m signing my own bank check, I’ll do it with the minimum expiration, one day, so if I lose I will have no problems, I can re-sign other.

But you’re going to sign a check for me, I prefer that the date is long, if it is one day and I have not received, I will have problems, or have to go back to ask you to do me another.

The same with a $100 bill, if you’ll give me, better not expire, do not worry, I’ll take care not to lose, but if I print, better expire soon.

There is no advantage at all in a short expiry date on the certificates unless you are yourself which signatures.

I think they are excuses, not reasons… the real reason is that they do not want responsibility, or lack the resources to higher expiration.

If indeed it is an advantage for us, and want to help us… given the option of expitación of 90 days or a year.

Note: Although I appreciate it, I do not need anyone educate me on automate task, or as I do my work.

5 Likes

Is there a concern that Let's Encrypt will hit its maximum capacity during general availability? Are OCSP responses such a burden that a 1-year validity period is technically impossible at LE's current capacity?

4 Likes

There is actually a flaw in this assumption. Looking at whats in the wild will not be representative of what people have demanded. Commercial CAs give very little flexibility here. Look at any of the major CAs out there - they offer 1,2, or 3 year validity.

Unless you run your own sub CA, like Google, you have to use a 1-3 year cert. While I have not checked your suggested sources, my own educated guess is that 1-year certificates are the most popular, but again, thats not so important.

The only other customers who would be able to control their validity periods are ones who dont mine asking CAs to reduce their validity below a year, but thats quite a luxury as I bet you they would still be charged for the full year each time.

Another pro not mentioned by JSHA is that short lifetimes reduce the work needed to implement new standards. When the SHA-2 migration was announced it posed a huge problem for CAs who had literally hundreds of thousands of certificates that needed to be manually reissued and reinstalled on end-users servers. Even just contacting all those users is a major effort. Same goes for migration from 1024 -> 2048 bit keys. Now the real problematic certs in these situations are the 2+ year certificates, however a 90-day certificate certainly solves the problem.

4 Likes

@jsha You said that LE ist limited because of OCSP signing. I know that it is required that the OCSP response is not longer than around 4 days valid. With 90 Days Lifetime this means around 20 times signing each OCSP response for one certificate. What would happen if you change the policy and say that only the last certificate for an FQDN will be available via OCSP maybe later one per key type. That will more effective limit the number of required signature than if you limit the lifetime. Also it would force that the user will take more care what they do with their certificates.
This will limit the same as if you say only 4 certificate per 90 days and fqdn.

2 Likes

tlussnig, there is one issue with that idea. In situations where you have multiple servers with the same host (a web farm), you may legitimately want each server to have its own certificate with a unique private key. This would reduce damage if one server is compromised, as you only have to revoke that certificate and none of the other nodes are affected. It’s not a common setup, but it is a legitimate setup that should be considered if you’re going to limit the certificates signed for a single CN.

2 Likes

Remember that a big part of our strategy is to write an API that anyone can implement and interoperate with. We expect lots of people to be implementing that API in the next few months. I personally think the majority of issuances, long-term, will come from hosting providers who have integrated our API. Starting with short certificate issuances means implementers are more likely to emphasize automation, and automation is one of our key principles.

Another pro: both Let's Encrypt and its Subscribers need to gain operational experience with automated issuance. This is a new thing we are doing, and it will take practice to get good at it. With renewals once a year, it would take many years for the TLS ecosystem, on both sides, to get good at automating issuance. Renewing six times a year gives everyone more practice, and we will get good at it more faster.

Like any good web service, we plan to scale to keep ahead of our growth, and we have a very generous window for the first year or two. But of course, we are a non-profit with limited funds, and highly dependent on ongoing funding in order to grow. And we may very well wind up issuing certificates for a large percentage of the web within a few years. Without going to far off-topic, my main concern when I talk about capacity is making sure that the capacity we have is allocated fairly and not spent on unused certificates, which is a big risk for a free service. There's a whole other thread to be had here!

Yes, this is definitely an important benefit. As Eric Mill put it, we need to turn issuance and installation from an emergency into the routine. That's a big part of why Let's Encrypt cares so deeply about automation.

This isn't a policy we can change. It's established by the Baseline Requirements, and for a good reason. If an earlier certificate was revoked due to key compromise, it would be important that clients be able to get that information. And, as @motoko said, some deployments use a unique private key per frontend.

4 Likes

Are you going to revoke certificates that you think are not used?

2 Likes

@jsha As far as i understand the baseline requirement the ca have to sign an positive response every 4 days.
But this is clear because it can revoked after 7 days.
But if an certificate was revoked, i would say the negative answer can be valid for the rest of the cert lifetime.
Because it is not like an physical key there i can say i want to use him again.

I know this leaves the point from @motoko with multiple sides. But with the same automation argument you can say they should automate the key distribution and if one server has an compromised key they should change change all with the same fqdn.

Since i am an java coder and can implement the cert reneval inside the keymanager it is no problem for me.
But there are lot of hosters that provide only webgui for cert deployment to their customers. So i can see why many people like longer duration.

3 Likes

@tlussnig In some cases you can’t automate distribution across nodes, or it’s difficult to do so. There are sometimes legitimate reasons for maintaining multiple certificates with the same CN but different private keys. If LE doesn’t want to support that kind of configuration, that’s fine. If you can afford that type of setup you can likely afford the certificate costs. However, that kind of configuration shouldn’t be discounted as a valid setup.

As for WebUI deployment, the emphasis is on automation, so I suppose the goal would be that those WebUIs are updated or changed so that a certificate can be generated and issued automatically without requiring the customer to even handle juggling CSRs, PKs, or other crypto details like they currently do. I’m not opposed to seeing an option for a longer issuance period if LE wants to try and cover those folks too. The emphasis right now seems to be on getting hosting providers to offer LE in a nice interface where the customer can just toggle on/off. Moving to that kind of penetration goes a long way in offering widespread encryption.

4 Likes

And very few of them that offer free certs, and no SAN certs. If the point is to get everyone using TLS, then LE should try to accommodate as many reasonable scenarios as possible. For those of us using TLSA and/or HTTP Key Pinning, where there is no automation yet, a 1 year lifetime is a reasonable compromise. Perhaps as LE matures and the client and automation processes around it mature, that can change, but for the moment it’s not unreasonable to support 1 year certs, especially when provisioning in manual mode.

6 Likes

No. It would be the wrong choice for a number of reasons.

2 Likes

So then, from Let's Encrypt's perspective, "not used" certificates are literally only for sites or servers that are no longer online at all?

I say this because once automatic renewal is implemented, wont the client continue to renew the 90 day certs even if the website admin is not actively "using" the site anymore, thus requiring the same exact OCSP load as longer term certificate?

3 Likes

I think one thing LE should do more is to make DANE (aka TLS + DNSSEC) more available, to push it more. I think LE is just a short term solution, and DANE the long-term solution.

That said, what is the problem ? DNSSEC doesn’t like short term information. I am not a specialist in this field. It is a complicated thing, but I really think that changing certificates often does not comply well with DANE, therefore I think it bad.

Thank you for considering that and debating.

2 Likes

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