Managing Certificate renewals after restoring from backups

My domain is:
www.oddcake.net

I ran this command:
sudo certbot certonly -a webroot --webroot-path=/var/www/oddcake.net -d oddcake.net -d www.oddcake.net

It produced this output:
There were too many requests of a given type :: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: oddcake.net,www.oddcake.net: see Rate Limits - Let's Encrypt

My web server is (include version):
Raspberry Pi 4 LEMP Server

The operating system my web server runs on is (include version):
Ubuntu 20.04 LEMP server, using wordpress.

My hosting provider, if applicable, is:
N/A

I can login to a root shell on my machine (yes or no, or I don't know):
YES

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
FALSE

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Certbot 0.40.0

Preface:
I am trying to understand exactly how certbot works when renewing and revoking certificates, FROM BACKUPS.

My Setup:
I am running a Lemp web/email Server on a Raspberry Pi 4. On the Raspberry Pi Server, I have set up a Crontab command that checks for certificates older than 30 days, and if they are older than 30 days, it automatically renews those certs.

So if the certificates are outdated, as soon as I plug in and turn on the server, the web/email certs will automatically update.

Occasionally (once every few days), I shut down my raspberry pi, remove my SSD, and make a complete cloned backup of everything on the disk in ISO format using a tool called ApplePiBaker.

This is basically the equivilant of DD'ing my rapsberry pi Hard drive to an ISO and then flashing it to another SSD.

The Obstacles:

I occasionally make a mistake on my Pi's setup, and then have to revert to a previously cloned ISO of the server image, by DD'ing it to another Hard Drive and plugging it into my Raspberry Pi.

Sometimes, before I can get SSH access to my raspberry pi, it seems to automatically update the cloned certificates, renewing them on that cloned reversion of my server image.

Then, often enough, I make a mistake on that cloned image, and realize I have to use a clone'd backup from even earlier than the 1st cloned image. When using that 2nd backup, again, it apparentely (according to emails from cloudflare) auto-renews my certificates on that cloned copy (the 2nd reversions).

The Problem:

What I don't understand is, if I renew certificates on an older reversion of my server image, and then also renew them on a second older reversion (even older than the first image), does that create two separate and individual certificates ? one copy for each clone? Or will the clones somehow automatically use the same certificates by updating a version controlled version of the certs from certbot?

Then, when I erase one clone (the first clone) because I no longer need it, and just use the second clone, are the certificates on the first clone still active, but not in use since the first clone was destroyed? And what If I then reinstall the first clone with the original non-update certificates? Will certbot attempt to update those certificates which have already been updated on an exact duplicate of the currently running server?

I'm aware that the best thing to do here, is to rsync the letsencrypt folder before destroying a currently running server image, and then transfering that letsencypt folder to any reversion that is going to be used, BEFORE the reversion can autoupdate the certifiates. But that sometimes is not always possible, as its easy to lose track of letsencrypt backups and which certificates belong to which server image sometimes. Also, Sometimes I just plain forget to back up the certs before destroying the currently running image.

The reason I have this question, is that I recently tried to revoke all my certificates in order to start from scratch. This includes revoking certificates on each individual cloned reversion copy of the server as well. After doing so I tried to renew the certificates.

However, when trying to run sudo certbot certonly -a webroot --webroot-path=/var/www/oddcake.net -d oddcake.net -d www.oddcake.net certbot tells me that I have to wait 7 days to install these certs because there have been too many requests to renew the certicates.

So my question is,

When I create and use these server backups, and its auto renewing my certs, what exactly is happening to each certificate on each cloned server backup? Are they becoming seperate certifcates? or is updating on one clone producing the exact same certificate as updating on another clone?

Please let me know how this works and how I can better manage this issue. Thanks!

Please don't revoke certificates simply because you no longer need them.
If you are going to play that way, use the staging system not the production system.

Yes.

2 Likes

This is something I did not do. Somehow my certificates got attached to other domains and started showing multiple certifcates on the ssllabs.com test. I revoked to try and remove the additional domains that somehow got attached to one of my certificates.

Please understand what revoking means and does before making such a request.

So very wrong!

2 Likes

If domains "got attached" to your certificate, they must have been on the same cert request.
Once a cert is made it can't be modified - EVER by anyone - even the owner.
Any change requires making a new one.
You have exceeded the limits allowed for duplicate new ones - and destroyed every cert given to you.

Production systems are NOT for testing.
There is a fully functional test environment for such things.

3 Likes

@DanRan This is a list of all the certs you have issued: https://crt.sh/?Identity=oddcake.net&deduplicate=Y

This history is why you are now rate limited. You say you only renew if cert is older than 30 days but that is not working any more. Also, you could wait for them to become 60 days old. This may avoid creating them unnecessarily when restoring from backup.

But, I agree with Rudy if you are in a volatile test situation you should be using the Let's encrypt staging/test system as well.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.