Certificate restoration

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:mail.prs-calarasi.ro

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version): Debian 11

My hosting provider, if applicable, is:

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):no

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

I saved the mail.prs-calarasi.ro certificate
with what command can I restore it?
because if they issue another new certificate

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: mail.prs-calarasi.ro, retry after 2023-01 -03T23:23:07Z: see Duplicate Certificate Limit - Let's Encrypt

You need to also have the private key corresponding to the certificate. Without the private key, a certificate is useless. You can find both in one of your more recent backups.

Certbot unfortunately doesn't have some kind of "import" command, so best is to just restore the entire /etc/letsencrypt/ directory from the backup.

5 Likes

that's what I did
I saved the whole directory /etc/letsencrypt/
I reinstalled the debian 11 system
and I copied the directory /letsencrypt/ into /etc
But it does not work
so I have all the keys

Could you perhaps specify that a little bit more? What exactly doesn't work? Certbot? The service using the certificate? What messages/errors/logs does it produce?

4 Likes

certbot certonly --force-renew -d mail.prs-calarasi.ro
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?


1: Nginx Web Server plugin (nginx)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)


Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator nginx, Installer None

Please choose an account


1: prs.prs@2023-01-03T12:55:56Z (29ae)
2: prs-calarasi.ro@2023-01-02T14:24:12Z (0191)


Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Requesting a certificate for mail.prs-calarasi.ro
An unexpected error occurred:
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 1 68 hours: mail.prs-calarasi.ro, retry after 2023-01-03T23:23:07Z: see https://le tsencrypt.org/docs/duplicate-certificate-limit/
Please see the logfiles in /var/log/letsencrypt for more details.

Why would you force a renewal if you just restored Certbot? I assume you've restored Certbot to a state including non-expired certs?

5 Likes

What shows?:
certbot certificates

4 Likes

certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewal configuration file /etc/letsencrypt/renewal/a.prs-calarasi.ro.conf produ ced an unexpected error: expected /etc/letsencrypt/live/a.prs-calarasi.ro/cert.p em to be a symlink. Skipping.
Renewal configuration file /etc/letsencrypt/renewal/mail.prs-calarasi.ro.conf pr oduced an unexpected error: expected /etc/letsencrypt/live/mail.prs-calarasi.ro/ cert.pem to be a symlink. Skipping.
Renewal configuration file /etc/letsencrypt/renewal/prs-calarasi.ro.conf produce d an unexpected error: expected /etc/letsencrypt/live/prs-calarasi.ro/cert.pem t o be a symlink. Skipping.


Found the following certs:
Certificate Name: l.prs-calarasi.ro
Serial Number: 3d14bb86a7730fa1d1b06df18d82f613553
Key Type: RSA
Domains: l.prs-calarasi.ro ll.prs-calarasi.ro
Expiry Date: 2023-04-03 12:55:04+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/l.prs-calarasi.ro/fullchain.pem
Private Key Path: /etc/letsencrypt/live/l.prs-calarasi.ro/privkey.pem

The following renewal configurations were invalid:
/etc/letsencrypt/renewal/a.prs-calarasi.ro.conf
/etc/letsencrypt/renewal/mail.prs-calarasi.ro.conf
/etc/letsencrypt/renewal/prs-calarasi.ro.conf

It seems your method of backing up or restoring it did not preserve symbolic links. The files in the /live/ directory should be (relative) symbolic links to the most recent corresponding file in the /archive/ directory.

5 Likes

I copied all the letsencrypt directory to /etc
so there is also an archive

what is the procedure to restore them
I mention that I have the entire letsencrypt directory
are there certain steps to follow?

You could try to run sudo certbot update_symlinks, but not sure if that'll work if Certbot declares the renewal file broken.

Otherwise you'd need to manually repair the symlinks using ln -s.

6 Likes

/etc/letsencrypt# ls
accounts archive cli.ini csr keys live options-ssl-nginx.conf renewal renewal-hooks ssl-dhparams.pem

/archive# ls
l.prs-calarasi.ro mail.prs-calarasi.ro

/mail.prs-calarasi.ro# ls
cert1.pem chain1.pem fullchain1.pem privkey1.pem

and now the directory with links

etc/letsencrypt/live# ls
l.prs-calarasi.ro mail.prs-calarasi.ro README

/etc/letsencrypt/live/mail.prs-calarasi.ro# ls
cert.pem chain.pem fullchain.pem privkey.pem README

I want to install our mail.prs-calarasi.ro

Please use ls -l as that would describe the contents of the directories way better: now there's no way to see if the files are symlinks or not.

5 Likes

cd /etc/letsencrypt/
root@prs-calarasi:/etc/letsencrypt# ls -l
total 40
drwx------ 4 root root 4096 ian 3 18:32 accounts
drwxr-x--- 4 root ssl-cert 4096 ian 3 19:00 archive
-rw-r--r-- 1 root root 121 mai 26 2018 cli.ini
drwxr-xr-x 2 root root 4096 ian 3 19:02 csr
drwx------ 2 root root 4096 ian 3 19:02 keys
drwxr-x--- 4 root ssl-cert 4096 ian 3 19:00 live
-rw-r--r-- 1 root root 721 ian 3 18:58 options-ssl-nginx.conf
drwx------ 2 root root 4096 ian 3 18:32 renewal
drwxr-xr-x 5 root root 4096 ian 3 18:32 renewal-hooks
-rw-r--r-- 1 root root 424 ian 3 18:58 ssl-dhparams.pem

Unfortunately that's not a very interesting directory to look at, I meant the subdirectories in the /live/ directory as they are the only dirs ought to contain symlinks.

5 Likes

live# ls -l
total 12
drwxr-xr-x 2 root ssl-cert 4096 ian 3 19:04 l.prs-calarasi.ro
drwx------ 2 prs prs 4096 ian 3 18:57 mail.prs-calarasi.ro
-rw-r--r-- 1 root ssl-cert 740 ian 3 18:32 README

/etc/letsencrypt/live/mail.prs-calarasi.ro# ls -l
total 24
-rw------- 1 prs prs 1854 ian 3 18:57 cert.pem
-rw------- 1 prs prs 3749 ian 3 18:57 chain.pem
-rw------- 1 prs prs 5603 ian 3 18:57 fullchain.pem
-rw------- 1 prs prs 1704 ian 3 18:57 privkey.pem
-rw------- 1 prs prs 692 ian 3 18:57 README

Those should all be sym-links.
I would move those files somewhere else [back them up].
And then re-run:

4 Likes

They're already from a backup :wink:

@ctinleonard Those files in /live/ should be, as said earlier, symbolic links to the corresponding files in the corresponding directory in the /archive/ directory. Use ln -s to make (relative) symbolic links. See man ln for the manual of the ln program.

Also, the user of those files seems to be "prs" and not "root". Did your backup not preserve ownership of the files? I don't know what backup software you're using, but ownership and symbolic link preservation is often a (very) good idea for backups.

5 Likes

There is no mention of its' continued existence.

4 Likes