Pros and cons of 90-day certificate lifetimes


@Octal The answer for this is to ask your hosting provider to supprort Let’s Encrypt. The process generates a new certificate, so you’ll have to install it again.

This isn’t really the right place to ask about this - Try creating a new thread in the relevant category.


but I dont think this might happen so quick. I just asked one domain provider whether they plan DNSSec (which is a bit older than DNSSec) and they said they dont plan it, probably because they dont want changes in their systems.


Yeah, I know it was a bit out of the main thread, just to clarify my point view. I mean, the 90 days cert wouldn’t be so bad if when you renewed it where valid for 90 more days, it’s posible in fact, the ACME could challenge the LE client to decrypt something with the privkey.pem (so, you probe your identity and you get notified by email, for example).
Instead of do a challenge to the server (again) which you already proved is under your control.

I don’t think any hosting will support a LE automated process, They sell hosting, domains and certificates, why will they change there business model in order to give free certs.


@My1 All domain registrars that handle TLDs that are regulated by ICANN have to support DNSSEC; you could always send in a report if they’re not going to do that and you have, for example, a .com domain.

@Octal Many of them don’t sell certificates; besides, it’d be good business to support LE, since users that want LE will move elsewhere.

Also, the cert would still have to be replaced, there’s no magical way to make it valid for longer, as far as I know.


well I guess pretty much all public tlds (including xyz which I use) are icann arent they? or are there some of the iana or whatever I dont really get all the organizational structure…

talking about making certs longer: it would be epic if there was a “ask the server for lifetime” cert which is essentially unlimited but enforces the asking of the server via OCSP or similar stuff. that way renewal could be handled CA-side.

not must-staple (which enforces stapling) but rather “must-check”…


I can’t help but feel like they’d have done this already if there weren’t technical issues. Probably easier to MITM.

Not regional stuff like .uk or .me. I think ICANN are in charge of .xyz, though.


well when the key gets out then it is easy to mitm but even if you enforce short lifetimes there will still be ppl who use the same keys everytime unless they actually notice that it’s broken, doesnt change that much. also making stuff

do you have it written somewhere “official” like the icann site, maybe I can pressure the hoster a bit.
and where can I report?


I guess, but stuff like certificate pinning does make MITM very difficult indeed - this would pretty much circumvent that.

Well, according to the ICANN wiki:

On December 5, 2013 XYZ.COM LLC received a Registry Agreement signed by ICANN for .xyz after passing all the required processes needed to become a Registry Operator for the string.

The compliance form is here, make sure your domain WHOIS lines up and provide screenshots with evidence.


Please do not get off-topic.
FYI here is a thread about using HPKP (HTTP Public Key Pinning) with LE:

If your discussion is related to HPKP you may better discuss this there.


I meant rather about the fact that all icann domains need dnssec, because they might know about the fact that it’s from icann but not about the DNSSec requirement.
because I really want to try to pressure them before reporting them.


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.


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.


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 ( much cleaner and easier to understand - and audit myself. Generally: don’t use the official client unless you really have to :slight_smile:


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


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.


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?

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


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.


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


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?


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