Pros and cons of 90-day certificate lifetimes

Okay, so if money is not the problem … why not opt for a certificate of payment that has more advantages? as the lifetime? Hey?

You defend the free certificates and accuse me of inreres for money is contradictory.

1 Like

well a hoster can also say, no I want the money people can only get the certs from me or do t on their own, and without SSH access this is not funny with LE.

3 Likes

Sure, if money isn't a problem and you don't want to be bothered, go buy a three year certificate from a major provider. Not everyone can afford to do that, though.

Sure, they can do this. Many hosters have charged for SSL capability even separate of the certificate. Shared hosting providers that continue to do that will be at disadvantage for those that offer security for free.

2 Likes

Most of you have not known the BBS:


I saw them being born and dying. (This is just to let you know that I’m that old) :slight_smile:

If I have learned in all this time it is that any system, automated or not, the possibility of failure tends to be 100% over time. If you also add a third part, updates, etc. disaster is guaranteed.

I sincerely believe that those who think that a short lifetime is irrelevant, do not have any experience.

6 Likes

I want to do cert stuff myself because then I can also do major updates if needed and similar stuff which would be plain annoying 6 times a year, and also lets me check that everything works as intended.

3 Likes

The exact same statement is true for any process involving humans. Both require monitoring. Even the big players sometimes mess this up (Google, Microsoft, ...). I would not feel comfortable using a service that doesn't monitor uptime and certificate expiration dates.

The recommendation is to renew certificates every 2 months. It's quite hard to get the client to actually break your existing certificates during renewal. With that in mind, you have a full month for your monitoring to notice any issues and for you to manually intervene.

(Yes, I'm aware this is not yet available on all platforms. It's a beta service, and it'll get there eventually.)

1 Like

Ok, all systems or organizations. 90 days multiplied by four the possibility of failure.

If I am signing certificates, also I prefer a short lifetime, I have already commented on another post.

Edit: 60 days multiplied by 6 :slight_smile:

Edit 2:
As you think you have more chance of winning the lottery, playing once a year or every 60 days?

Well never touches the lottery… but… the software failure always plays! not multiply your chances of winning!

Edit 3:
If I can save a lot, I can risk one day fail. But for $20 I will not take that risk, or anyone who knows math.

2 Likes

Why would restarting SMTP be so dramatic? I do that so casually it almost starts to look like a hobby.
A properly configured mail server always undertakes more then one attempt delivering e-mail in the event the mail server is down so the chances of actually missing mail is extremely small even if your server would receive an e-mail in the few seconds you happen to be restarting postfix, or whatever it is you use.

1 Like

Server not reachable should be a temporary failure, just like greylisting.

The only effects from an hour of downtime are some delayed mails (other mailservers are doing some exponential backoff, so expect like up to 6 hours delay when it were 1 hour downtime) and no spam from that time ;-).

AFAIK the spec says a standard compliant mailserver needs to retry for up to 5 days before giving up on the mail.

1 Like

like your service but need 1 year

how to automate on nginx without stopped the server ?

1 Like

Use the webroot plugin and reload nginx gracefully, typically with service nginx reload (depending on your distribution). This works without any downtime.

1 Like

Just had to install SSL manually using Vagrant for a website on a shared host that doesn’t allow SSH access (pff). It would be okay for LetsEncrypt to allow for longer certificate expiry. Thinking of getting certs for subdomains of the page is tedious. 1 year cert expiry option would be really okay.

=> Most people using crappy hosts who for one reason or another do not provide SSH access and or sudo access would be able to benefit from just having to install certificates once or when its compromised.

2 Likes

IMO short lifetime has a massive upside, in fact, I’d accept certificates that only for a few days, or even less (but let’s assume <1d is silly because of clients without time synchronisation or internet outages).

The whole point is that process is automated.

In fact, it provides a stronger security guarantee – control is (or can be) re-validated every time certificate is updated.

And when something is automated, it’s much better when it fails earlier than later if there’s a bug, misconfiguration, etc.

2 Likes

So with 166 likes out of 212 replies, and some pretty compelling evidence that restricting the cetificate lifetime to 90 days is not workable for a large segment of users, there any movement on allowing longer lifetimes? I’m fine with leaving the default at 90 days, but at least allow us to set a year, even if it’s just for the manual provisioning.

A quick summary of scenarioes where 90 days certs are going to be painful:

  • HTTP Public Key Pinning (HPKP)
  • DNS-Based Authentication of Named Entities (DANE)
  • Daemons that need to be restarted to load new cert
  • Embedded devices (firewalls, load balancers, IoT, etc)
  • Systems where automation is not yet implemented (ie Windows/IIS, various daemons, etc)
  • Systems where the the user doesn’t have access to the LE client (shared hosting, etc)

It’s my belief that if the primary mission of Let’s Encrypt is to get the entire Internet using TLS, then that mission is being compromised by this relatively arbitrary restriction. Sure, automate where you can (the lowest hanging fruit / most impact) but this blind insistence that everything must be automated seems foolhardy, and means you’re not capturing a very large proportion of users that would otherwise use the service (myself included).

Another common complaint is that there has been almost zero feedback from LE itself (other than creating the topic). This topic has been going on in one form or another for almost 8 months now, and we still have little if any feedback from LE, and no progress despite a clear case for allowing longer lifetimes. So where do we stand?

6 Likes

My problem with this whole topic and the "like" to agree is there is nowhere to disagree. So there is no way to get a consensus. Personally I wish the timescale was shortened a lot ( although I understand it would need to be done steadily as you need to ensure automation is complete before shortening it too far). There is no "disklike" option though, so very difficult to get and understanding of which is preferred.

2 Likes

I see this a lot here, but I wonder what you'd consider appropriate as feedback on this matter? Let's Encrypt is obviously aware that there are some use-cases where automation can be hard to deploy or where short certificate lifetimes make certain things harder to implement.

I'd wager they were aware of most of the implications even before this discussion was started, and they still made a conscious decision to enforce short certificate lifetimes. They decided that short certificate lifetimes will force more users to automate certificate deployment, that it will force vendors to make it easier to deploy new certificates (without downtime), and that the security benefits of certificates with shorter lifetimes are more important than the fact that some groups of users might not yet be able to utilize Let's Encrypt.

If you're an organization with the long-term goal of securely deploying TLS everywhere, I certainly think making decisions that will eventually force everyone to make security-oriented choices is a good idea, even if it means that not everyone will be happy with the service just yet.

4 Likes

Couldn't agree more :slight_smile:

2 Likes

why doesnt discourse have a poll feature?

2 Likes

The fact that Let's Encrypt offers free certificates is never going to even tempt an IoT vendor to implement some sort of automation. Even vendors like Cisco, while you can technically automate it yourself with a big time investment, will never proactively support something like Let's Encrypt.

There are just too many use cases, you'll never be able to automate them all. And LE is just causing undue pain for these cases for very little gain.

5 Likes

It may not tempt all IoT vendors to implement automation, however I think with over 1 million certificates issued when starting from scratch only 16 months ago and growing at a current rate of more than 100,000 certificates per week … Let’s Encrypt haven’t got it that wrong and a lot of people are implementing automation.

2 Likes