Maximum (and minimum) certificate lifetimes?

I guess at this point I’ll rest my case and reiterate the primary goal of the project, as far as I understand it, that is: making http connections encrypted (green/grey lock in the browser address bar). Anything else goes beyond the initial scope.

2 Likes

Those large attachments are not problem. The master will just spawn new workers and the old workers will stop accepting new connections, but handle the remaining ones.

The point is that you should automate it, so you don't even have to think about it anymore. No other CA provides this as of now.

2 Likes

Yeah, but then we've just come full circle, lol. We can't automate everything. And expecting projects that don't support live-reload of SSL certs (such as IRC servers) to suddenly implement that is a narrow, somewhat greedy view of the situation.

I agree that automating this stuff is the ideal end goal, though. Automatic certificate renewal? Fantastic! But it's just not possible right now.

5 Likes

If you don’t start now, when do you want to start? It’s time to implement zero-downtime restarts now, it’s 2015.

1 Like

I can see both sides, but as to when do you start - most folks (who are not system admins i.e. end users) will only start when automated process are available through the web stack or software providers own offered software. For example, when apache, nginx and other TLS using software can natively offer such automation to make the process easy.

2 Likes

Totally agree with you, but I feel like a sledgehammer approach won't help much - perhaps allowing only the 90-day certs to be managed automatically while still allowing the traditional one-year certs for manual generation only? That way you're still encouraging people to automate (as the process would be a lot easier), but not leaving others out to dry.

Later on, when software's been updated, you could switch entirely to the 90-day cert.


Probably not the ideal situation if you're trying to get people to automate everything, but it seems like a good middle ground.

5 Likes

So I’ve read this thread twice, and I keep coming back to this observation, the primary stated goal of this project appears with in reach. A vast swath of websites will easily benefit from the Let’s Encrypt model. While other implementations may not as described earlier. I tend to think of Let’s Encrypt as another tool at our disposal for administrative duties.

Each use case will need to be evaluated regardless before implementing a structural change to an environment that could potentially effect the core security of customers/clients. So while I do understand both sides of the coin, I am not thinking of this model as a pro or con, but more along the lines of, “will this user case scenario work well for this environment?”.

In my case, I can see this model working for 80-90% of my clients.

–…Archer

4 Likes

Sure, nothing wrong with that, as long as the client isn't rechecking the certificate it got at the start for expiry (not bloody likely lol). The TLS session is already established, it's not like you're changing out the session keys or the cipher.

2 Likes

Actually, I don’t think it is a narrow way of thinking about it. The fact that this absolutely critical service (Whether it’s Email, IRC, or whatever else) can lose data or have a negative impact on your business by the service restarting is an indication that the deployment is not as robust as it should be. There should be another server running by its side and the client should gracefully failover to the alternate server, allowing full restarts of a single server as and when needed. I appreciate that not all pieces of software support this, but I think you should consider the cost of one of your servers needing to be restarted and from that decide whether or not these pieces of software are suitable for your business, or if you should be finding other providers. Obviously config reloading negates some of this, but it doesn’t solve the fact that your business is dependant on these services being up constantly and cannot cope with any downtime, which for me is a serious risk.

By using the sledgehammer approach, Let’s Encrypt will help speed up the software improvements required in the same way as the major browsers dropped support for SHA1 certificates and native browser APIs to force change in an otherwise stagnant software world. When the softly-softly approach is used, the end result is usually that no significant changes actually occur.

In response to your comment about forgetting to renew your certificates every 90 days - How do you currently remember to renew your certificates every 1/2 years ? Whatever process you use for this can also be applied to the 90 model. You should use a reminder or tasks list to ensure that your certificates are kept in-date regardless of how long they last.

1 Like

While I agree that it would be fantastic if all software worked in that way, this isn't always the case and some products might be proprietary, archaic, poorly-written, or all of those things. Particularly with larger or older businesses, you may get some ancient software that has no alternatives that the developers no longer really give a damn about - or make you pay through the nose for upgrades.

What would you say to those people?

Because it's at the same time as my domain renewals, although I agree that isn't an ideal way to remember.

1 Like

Well it’s really a business decision to use these older and more archaic products. The decision essentially boils down the to cost of using that piece of software (Cost of supporting an old piece of software, cost of it not being as highly available as it should be, cost of not being able to offer the latest features to your customers, etc) vs the cost of using something different (Cost of buying new licenses, cost of developing bespoke software, cost of the risk of changing software vendor, etc). Ultimately by deciding to use or start with these older products, the decision has been made that availability is not as critical as some other factors and that some downtime every so often is acceptable. Of course if this is not the case then I’d suggest re-evaluating this decision.

I do appreciate that there aren’t always alternatives to a piece of very old software, but in this case the decision is between using it and not using it at all. I do also of course appreciate the additional cost and annoyance of having to go through a renewal process every 90 days. That in itself is part of the decision that I mention above, the cost of renewing certificates should be carefully considered and should be factored in. This is something you have to decide on as part of a case by case decision for your own company.

I’d strongly suggest that even if you stick to your existing 1/2 year certificates that you use reminders of some sort to let you know when you need to action things like domain and certificate renewal. It will also serve as a nice way of handing things over to your successor should you ever move on from the company.

I say all this knowing that automation isn’t as easy as it sounds. When I work, we recently automated the deployment of our entire software stack to Amazon. I say entire but the truth is that some parts are still manual. We made the decision that at the time it was more time efficient to keep the manual steps in there, but we are at least moving towards full automation.

6 Likes

This is actually a pretty great answer. Thanks for taking the time to type it out.

I think you make a fair point here - Different priorities mean different considerations. Good way of looking at it.

2 Likes

Here’s another point: It forces you to make reissuance easy, because it turns an emergency into the routine.

https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1#changing-certificates-shouldn’t-be-this-hard

With LE, the client can update and automatically reissue your certificate with updated parameters.

4 Likes

I think there are two different points between how easy reissuance is and what is the forced maximum time.
Because it is already said that you can recreate the certificate before the time.
Also small Lifetime mean much data on certificate transparency but small CRL.

1 Like

I don’t see mail servers as problematic. SMTP as protocol is specifically suited to unexpected interruptions, resending, backup routing, and (contrary to popular belief among users) being ok with reasonable delays, so that restart and interruption is IMHO just a bit annoying rather than critical. Granted, an email that requires an unusually long connection (due to large attachments or low use of bandwidth) might need to unnecessarily resend a lot of data - but that situation could also happen once a year instead of once every three months. Especially, if you’re able to schedule it to off-hours (and off those hours where you routinely send around those DVD attachments) I don’t see a problem. (Client submission may be a different situation though than receiving or relaying).

I do see your point regarding VPN services that are more expected to be highly available and low-latency. Then again, we already have key renegotiations every few hours - so maybe the software could also be made cope with certificate renegotiations every few months?

But then again, the recurring theme of this thread kicks in: The short lifetime makes it absolutely necessary that the processes can be automated. And those automated processes must run very reliably.

1 Like

A shorter lifetime also does a lot of encouraging on the CA side to automate renewal processes and ensure 100% uptime. After all, you may expect 4 to 8 times as many renewal requests from the same number of clients than a CA issuing 1 or 2 year certificates. Actually, if the renewal is attempted after 60 days already, we are at 6 to 12 times as many requests.

1 Like

will you ever issue them for 3 or 6 years?

1 Like

If anything, they will probably issue certs for even less than 90 days of validity later on. Also 3 years is the absolute maximum lifetime permitted by CA/B Forum, so 6 years is out of the question.

EDIT: I’ve just reread second post in this topic, which confirmed my suspicions.

1 Like

And encryption scheme are constantly evolving to stay several steps forward (it's a cat and mouse situation). You also wouldn't want to use a non-expiring certificate that is still using SSLv3 and remain vulnerable to attack because of inaction on your behalf.

1 Like

@m-p-3, most of the cryptographic parameters used in a TLS session aren’t specified by the certificate, but only during the TLS session negotiation. For example, you could use a Let’s Encrypt certificate with 56-bit DES as your cipher, if the client and server were both OK with that. The certificate just doesn’t set most of these kinds of policies today, historically because CAs didn’t think it was their responsibility – rather, user-agents thought it was their responsibility to negotiate safe options (and the client and server can upgrade to better cryptography, with the single exception of changing the subject public key itself, without reissuing the certificate).

I agree that it would be useful to have administrators or at least operating system developers revisiting their crypto setups more frequently than they do today, which is often “never”.

1 Like