Pros and cons of 90-day certificate lifetimes

Ah, sorry. Here.

Now, I suggest that we start getting back on topic. Feel free to send me a private message or start a thread if you need more on this.

2 Likes

I will insist, I have the feeling that make us waste time.

If you have enough resources to provide greater than 90 days expiration, do it and let me decide what is best for myself. I appreciate your advice, but the decision is mine.

If you do not have sufficient resources, say it clearly and stop presenting this as an “advantage” for us.

We all know that from the point of view of the issuer of the certificate is a short expiry better, but I think that is not the debate.

3 Likes

I also strongly encourage the option to have longer certificate lifespan. If you’re concerned this does not work with your current API: well just add an optional parameter during request where one can specify their own validity period and only sign if it’s between 90 and 360 for example. No real need to change the API fundamentally there.

Automation is all well and good but you loose control. And certificates is something I definitely don’t want to loose control here. I thought you were all for a more secure web here. And what did Murphy say?

The main issue here is, that you advertise Let’s encrypt that everyone should use and is very easy. To some extent it is, but still you need to have a fundamental knowledge of SSL/TLS, X509, IT security and basic webserver operation to do so. As others mentioned this 90-days lifespan somewhat feels like “I know better then you” and I’m somewhat offended by that. And when you start taking control out of something, people will let it run without checking up on things, and this is far worse than having something like heartbleed: it’s having heartbleed and not fixing it.

Yes there’s stuff like heartbleed and Debian SSLKeys, but they took several years to detect. Nothing here to help you with 90-days certificates. And to be safe I have to renew the certificates anyway (and in case of SSLKeys I have to generate a new private key too).

Also these are problems in the implementation not the concept of SSL/TLS. Imposing a 90-days lifetime is a change to the concept to avoid problems of the implementation. So it’s like aspirin: helps you against head-aches but it doesn’t help if you have a brain-tumor causing your head-ache. So it would be much better to fix the brain-tumor than to numb the pain and ignore the tumor.

@raairb: finally someone is on the same page as me, that think installing gcc on a productive server, might not be the beast idea of all time. use acme-tiny (https://github.com/diafygi/acme-tiny). much cleaner and easier to understand - and audit myself. Generally: don’t use the official client unless you really have to :slight_smile:

3 Likes

one of the best ways to explain a workaround, ever.

1 Like

One big con: Shared hosting.

If the goal is really to encrypt big parts of the web, then you have to keep in mind, that the majority of websites is hosted by shared hosting providers.

My hoster allows me to edit my HTTPS keys for free and so I could add free letsencrypt keys to my domains. But I have to copy&paste the content of the key files to text boxes in a web GUI. Doing this every few weeks is just too much hassle for me, so I will not even start with HTTPS so my visitors don’t expect this to keep available.

Doing this once a year would be OK. So it would really help me if there would be optional setting to set the lifetime.

And: Please set up some web interface to request a key to make the whole process easier.

6 Likes

Currently it's six times a year, and they are asking for feedback. Obviously, it's not a set-in-stone thing that won't ever be changed.

You mean like this? https://gethttpsforfree.com/

There are many other tools listed at List of Client Implementations. Find one that works best for you.

1 Like

Anyone can tell me how gethttpsforfree should work ?
The requests must nonce must be signed with the account key that the page does not have.

1 Like

you sign yourself and paste the result, the page tells you the commands and stuff

1 Like

Why does it need to be a predefined period of time?
Why can’t the expiration date be a variable as long as it is within a “reasonable” set of values?

2 Likes

This is already explained. It is related to OCSP. And since the private key is in HSM there is an rate limit to signatures and it is an storage question with ocsp

1 Like

Hi again from the Godwin’s Law guy.

There is still no credible reason to prevent choice, asking for use cases is a red herring.

I am curious what would make LE offer variable key lengths, perhaps a competing free CA with 1-39 month lifetimes and an API might let them see the light.

However after reading this second long thread I have come to the conclusion that we are being too hard on the LE developers here, they are being compelled and are doing their best to try and warn us without actually telling us that they (and any other CA out there, even those that do not warn us, and any other free CA in the future) do things without good reason, because the NSA (or whoever) has made them do it, and they cannot speak of it.

2 Likes

well cant the private key be copied to a second HSM to have another machine help with the sigs, also in my opionion it is stupid enough that a revoked cert’s OCSP has to be signed every like four days, it’s a standard but it’s stupid and inefficient, there just have to be a response was revoked and signed once for all eternity, I mean you cant really un-revoke a cert, or at least that’s not how it should work.

@KalleMP @tlussnig said already that hardware capacities play a role in here because OCSP (something like short-time assurements that the cert is still valid) need to be signed like every four days for ALL certs including revoked ones, unless they arent expired yet so when a cert expires it is invalid by its own definition so those dont count into the OCSP load and therefore revoked certs place a burden for quite a shorter time than they do when we have a year or more.

1 Like

I must have missed that lesson (as I did all the others) but explain to me how 6 certs with 3 month lifetimes is better than 1 with a 13 month lifetime in this case. There is duplication for 1/2 of the certs lifetime in one case and in 1/12 of the lifetime in the other case. Both cases offer cover for 12 months but one has 19 months of certificate storage and the other has 13 over a 1 year period.

I'm hoping there is a simple answer but cannot see the storage savings at this time.

EDIT:
Sorry, I'm just coming from the regular use case model where certs that are issued are used as I hope will be the case in most circumstances.

2 Likes

well the point of this is revoked certificates. if you revoke a 1 year cert the OCSP still has to make responses for the rest of the time, which is a lot shorter on 90 days certs. I know that is insane, but I cant change that.

1 Like

Yes, but that is only 4 times higher storage requirements for revoking 12 month certs to 3 month certs, that is a edge case that can never happen or there would only be revoked certificated in 'service'. What if we were to calculate storage and other overhead on working certificates and decide lifetimes based on that instead? Real numbers here would be nice, the one post above was quite descriptive on working storage sizes but would those change massively if the certs lived for their optimal life times instead of having overlapping certs.

2 Likes

well that is ture as well I am personally also for longer certs, but I just wanted to give an insight of their reasoning.

1 Like

Hi all,

Apologies for the absence, we've had a busy week.

This is interesting! But I don't think I agree. There are extensions like CertPatrol that allow people to be notified when certs change for sites they visit, but these alerts are generally not actionable even in today's Internet. There's no way as an end user to tell whether an unrecognized certificate is legitimate or not.

Fortunately, Certificate Transparency offers a way to formalize that "watching" process and make it public and actionable. Site operators, the only people who are really empowered to judge whether a given certificate is legitimate, can subscribe to monitors and be alerted when new certificates appear. End-users can (eventually) be alerted if they are presented with a certificate that hasn't been publicly disclosed.

That leaves HPKP pinning. I assume you are talking about pinning to leaf certs rather than intermediates, because that is the only kind of pinning that is materially affected by 90-day lifetimes. It's still quite possible to pin leaf certs with 90-day lifetimes. You have to either pre-allocate your next N keys and include them in your pinning header, or as you say, reuse the same key across multiple issuances. I'm not sure that encouraging long-lived keys is likely to increase people's successful deployment of HPKP pinning.

It's number two on our list of key principles, second only to "free."

4 Likes
2 Likes

I think your points in the linked thread have been thoroughly rebutted by others, and you haven't replied. It seems more appropriate to continue the conversation over there than to try and repeat the same innuendo here with no new arguments.

1 Like

I find it quite telling that neither you nor anyone else identified as a LE representative or spokesperson has addressed it directly. I think you’re gagged.

3 Likes