0
Let's Encrypt certificates expire after 90 days. There are tools for automatic update (replace expiring certificate with fresh one which is valid next 90 days). Is there a method to make this change 100% smoothly without broken links, failed SSL handshakes, wrong cert messages, etc?
i486
Posted 2019-03-18T20:57:21.713
Reputation: 163
2
The answer would be "it depends on whether the server application was written correctly", but I think the premise of the question is false.
@Ramhound OK, but at one moment current certificate file will be replaced with new one. If a SSL handshake is in progress in this time it can use old and new certificate or something of this kind. I don't know all details how are used the certificates but I guess an interruption may occur at least in one SSL connection if the certificate replacement is not specially handled (in OpenSSL, web server, etc). Somebody may say that 1-2 broken connections are not big loss but if it is possible to avoid this will be better. – i486
It doesn't work that way. The TLS library doesn't re-read the cert file every single time – it reads the file once and works with an in-memory representation through the entire handshake. In fact, usually the TLS library won't even notice that the certificate has been renewed unless the program specifically tells it to re-read those files. With most TLS-based daemons, you need to explicitly trigger a configuration reload after every certificate renewal.
When that's done, the new certificate data is normally loaded into a new memory location and any decent TLS library will still keep holding onto the old data for as long as it needs to coomplete the pending handshakes, only switching over for new connections.
(For example: OpenSSL uses a 'context' object – a template from which connections are built, and SSL_CTX_use_certificate() appears to explicitly document that any changes to the context do not affect existing connection instances, although there is a related discussion on GitHub, so programs might choose to create a new context outright for safety.
Similarly, in GnuTLS, loading a new certificate will allocate a new gnutls_certificate_credentials_t and existing sessions will continue to use the old one.)
So the "special handling" you talk about is already there and enforced by API; it's already the normal way of handling things.
Note that all TLS certificates eventually expire and all of them need to be renewed and replaced – this is not in any way specific to Let's Encrypt. In fact the situation is usually worse for long-term manually-configured certificates, because those are often renewed only several hours or days after they have expired (and after someone notices that new connections are already showing alerts), whereas the usual LE automation takes care to perform renewals at least two weeks before expiry.
user1686
Posted 2019-03-18T20:57:21.713
Reputation: 283 655
I guess the last paragraph is the most important one: if you can't figure out how to automatically renew your certificates, you'll have a problem – no matter if they expire every 90 days or every two years. – slhck – 2019-03-19T09:56:07.147
2Those same tools should do exactly that since Let's Encrypt certificates are not renewed but new certificates are simply issued, the scripts that run every 90 days should handle everything that is required (in my experience) – Ramhound – 2019-03-18T21:00:27.657
@Ramhound OK, but at one moment current certificate file will be replaced with new one. If a SSL handshake is in progress in this time it can use old and new certificate or something of this kind. I don't know all details how are used the certificates but I guess an interruption may occur at least in one SSL connection if the certificate replacement is not specially handled (in OpenSSL, web server, etc). Somebody may say that 1-2 broken connections are not big loss but if it is possible to avoid this will be better. – i486 – 2019-03-18T21:09:27.727
1first, if the website is that important, don’t use let’s encrypt. HTTP is stateless. Every request is a new, and fresh request and the browser spends most of its time idle. Meaning the moment the certificate changes the very next request will contain the new certificate and work fine. It isn’t like you’re interrupting some “on going” connection. – Appleoddity – 2019-03-19T04:28:06.597
Your question is very vague. What specific problem are you facing, and how can we help you solve it? – slhck – 2019-03-19T08:09:09.367
@slhck My question is because of short life of LE certificates and the need of frequent updates. I am not sure whether the certificates expire in 90 days because they are demo or temporary solution with expectation to buy normal certificate or they can be used for long time (e.g. 5 years). For that reason I asked about smoothness of update process. – i486 – 2019-03-19T08:59:18.177
1
Let's Encrypt certificates are not "demo" certificates or a temporary solution. Please read the Let's Encrypt documentation and https://letsencrypt.org/2015/11/09/why-90-days.html – the main point being that updates are automatic anyway, so it's not a problem to keep these times short. But if you (apparently) have not tried installing a LE cert, or auto-updating it, what's the point of this question? I recommend you try it first, and if you run into specific issues, come back with a question about that problem.
– slhck – 2019-03-19T09:54:37.2701@Appleoddity Sorry, but advising users to not use Let's Encrypt on important websites is a bad idea. LE certs are as good as any other certificate. Your argument is also invalid, because TLS encryption has nothing to do with HTTP being stateless or not, or the client re-reading the cert with any request. Please read the below answer. – slhck – 2019-03-19T09:59:07.590