Renew very old certificate / renew triggering the limits?

[DeCato]

I use a Docker machine on Azure with a ‘let’s encrypt’ certificate.
Once the project is finished the customer will handle the machine so we want to have as little intervention as possible.

Our first approach was to request a certificate at every startup, but Azure can have it’s glitches and multiple reboots can hit the limit of the numbers of new certificate requests/week, which could potentially lead to a downtime of a few days given the 5 request/7days!!

We are now looking at the approach of getting the certificates once and make them part of the docker image and then do a renew at startup. This will work for now, but if the server starts a few years from now with the same x years old certificates baked into the image, will it still renew to an active certificate?

On the other hand I read somewhere that a renew is just another way of getting a new certificate, so will this potentially trigger the same 5 request/7days limits (as each time the docker restarts with the old certificates baked in, it will have to do a renew to be valid).

Is this an approach we can safely use in a production environment?
Is there an easy alternative?

[JuergenAuer]

Hi @DeCato

both options are bad.

You should save the account key and the certificate outside of your docker environment.

Then create one certificate, use it 60 - 85 days, then create the next.

Storing the certificate and the account inside an image is always bad.

Something goes wrong, the client restarts the image, 2, 3, 4, 5 - and the domain is one week blocked.

[schoen]

While agreeing with @JuergenAuer that you should look for other alternatives, I’ll note that the answer to your question is that certificates can always be renewed even after they are already expired.

[mnordhoff]

But if you repeatedly boot an extremely old image, ‘renew’ the certificate (which is just a term for issuing a certificate), reset it, and repeat, you can still hit the duplicate certificate rate limit.