Pros and cons of 90-day certificate lifetimes


Too detectable. Not covert enough.
Only works for live session (MITM). Not post capture analysis (of non-MITM).

Gov surveillance entities what to get away from needing to use MITM techniques.


Then what sorts of back doors are you referring to in your post ? I believe that only the use of weak algorithms would be a viable attack and that attack is mitigated by the use of certificate signing requests - I.e. The private key is generated by your client and never sent to the server, as mentioned by @Leliana.

It should be noted that even with perfect forward secrecy, any captured sessions are still at risk of being exposed if the underlying cipher is broken. This feeds back into the earlier point of shorter certificate durations being more secure in this regard, as breaking the cipher for one session exposes a smaller amount of data, requiring more computing effort to expose data over a period longer than 90 days.


You’re making an assumption regarding their lack of ability to build in backdoors. I’m saying their ability far exceed that which is commonly known.


Well to be fair, you also seem to be making assumptions about their abilities unless you can provide some evidence or even just specific examples of their capabilities. Without any specifics, it’s hard to discuss the point you’ve raised.

Of course if we assume that their capabilities are really that advanced, it would seem that SSL would do little to prevent their snooping if they really wanted to do so. I’m not certain what benefit they’d have from having access to the public portion of the certificate signing process alone aside from the afore-mentioned MITM attacks ?


Reminder: Discussions of how to go about backdooring a CA are offtopic for this thread, which is about concrete pros and cons of 90-day certificate lifetimes. @NOYB helpfully started a thread at Surveillance Advantages of Short Lifetime Certificates if you’d like to follow up there.

Also as a reminder: If you are posting to express your support for longer lifetimes, without discussing a specific pro or con, please “like” the first post in this thread. This helps keep the signal-to-noise ratio high.


BTW Congratulations on reaching public beta! :smiley:

Not true. There are a few (admittedly rare) cases where a user can trust a cert without having to rely on the CA trust model.

eg: if a cert has been observed in use for a while, or (re)uses a subject public key that has been, the end user can be fairly confident the cert is legit, particularly because of things like:

But if switching both certs and keys really often becomes common, those few cases in which users can effectively practice this kind of self-defense become even rarer.

And, of course, it’s no real comfort to:

…if you’ve got to decide today whether to trust a site with your password or not, and live with the results (users are the ones most affected by MITMs, not site operators or CAs).

I just read that the LE renewal script will default to generating a new key rather than re-using the current one:

I really hope that’s not true. If it is, I hope it’s due to some practical barrier or other that I can help remove?

Obviously there is a trade-off and we wouldn’t want keys being re-used for 10 or 20 years either! I would suggest LE defaults to re-using the same key for 1 or 2 years.

Key rotation at reissuance

I’ve always been against pinning as it causes problems when you want to quickly change algorithm after a vulnerability has been detected and ultimately offers little benefit if you trust the trust model. We fell foul of this at work where we needed to change from sha1 certificates, but other teams using our service were pinning on our old certificate - These teams had native desktop applications which has no forced update method even within a longer period such as 6 months.

Additionally not rotating the keys frequently negates one of the main security benefits of using short durations so for these reasons I would be against the proposition of retaining the keys, especially as a default option.

Pinning and SHA1 migration

well I would say that TLSA Pininng works a lot better because they dont rely on long-term-storage of the browser.

also since keys are used for the pinning a sole change f the algo wont hurt pinning, also you should always have some backup keys.


I’ve forked off the pinning conversation over here: Pinning and SHA1 migration.


That’s a very big if. Why would you trust the CA trust model?

It’s thoroughly broken for the purposes of defending against nation-states, and partly broken even for defending against smaller attackers.

Edit: Sorry for starting a tangent, I posted this before I saw jsha had forked the conversation and can’t see an option to delete post, only edit.


I think you missed the “by default”. :wink:
You can always let the client ask to only renew the cert and not to regenerate it every time.


I was going to generate one for my Firewall… until I notice the 90 days :frowning:


I like certs being used for 90 days, but I’d renew them 30 days before they expire. An expiry time of 120 days seems more reasonable.

The automated renewal would be very good. Particularly if a multi-step process was set up for the manual version to allow people to script things for their internal systems.


90 days is very short for manual updates. It would be nice if the default would be 1 year, so that those who have to manually request and update certificates have less work to do. It would also not be much of an issue to use the 1 year period for websites where security issues are less critical.

You can then let people specify via a commandline option if they want shorter periods (90 days, 120 days etc.) for those who have bigger security concerns and who use automation.

I think this would make everyone happy.


Why would you default for the longer lifetime? The idea behind Let’s Encrypt is automation. If for some reason your server or your policy doesn’t work with that, you are the outlier here. It would stand to reason that if Let’s Encrypt would implement a longer certificate lifetime, this longer lifetime would be optional, not the default.


That would indeed be better Osiris. Let the default be 90 days, and allow people to specify a longer (1 year) lifetime via the commandline.


I dont care about the default, I only care about heing able to have longer times. even if the default is 12 hours.


What would be the current liability for LE to support the scenarios listed in the cons? I suppose if something bad does happen later on for the more complicated/risky/uncommon scenarios that are harder and more complex to support, it would burden and harm the reputation of LE, so considering the early stage of the project, and as a user who can already benefit from automated 90-day certs, I would rather have them focus on making the existing policy as solid as possible (and not winning over existing customers of paid certs)

In the mean time, the respective niche communities can still work with LE to explore ways to utilize/automate the existing process, until it improves to the point when supporting non-mainstream devices is deemed not so risky and can be done with minimal burden to LE.

In summary, longer duration certs (for the convenience of supporting a wide range of uncommon scenarios, e.g. non-webservers with limited exposure to internet) should have lower priority given early stage of the project.


There are ways to automatize this. For example python has the mechanize module, which can act like a browser. So uploading a https-certificate would be possible. You need to run this every 60 days on some workstation, though.


People will waste more time in pursuit of trying to automate due to the short cert life time, and dealing with automation issues, than they would manually renewing once a year for the next 20 years.