New folders were created when renewing wildcard certs

Help
1

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: *.scicat.ess.eu

I ran this command: certbot --text --agree-tos --non-interactive certonly --rsa-key-size 4096 -a dns-rfc2136 --cert-name '.scicat.ess.eu' -d '.scicat.ess.eu' --dns-rfc2136-credentials /etc/letsencrypt/dns-rfc2136.ini --dns-rfc2136-propagation-seconds 10 --keep-until-expiring

It produced this output: Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/.scicat.ess.eu-0018/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/.scicat.ess.eu-0018/privkey.pem

My web server is (include version): haproxy 1.8

The operating system my web server runs on is (include version): CentOS 7.9

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.11.0

2

If you run that command each time, it can happen.

Just run certbot renew next time.

2 Likes
3

Also, check which certs (and paths) are actually active/useable with:
certbot certificates

3 Likes
4

Wait, but with --cert-name specified explicitly it should not create a new directory like this.

Specifically, the use of --cert-name should result in not having the -0018 suffix.

@_az can you think of what could cause this? It actually seems like a bug to me (although conceivably one that would have been fixed in a later Certbot release).

4 Likes
5

The only thing I can think of is if somebody manually messed around with the contents /etc/letsencrypt/{archive,live,renewal}/.

One way to reproduce this bug is to:

certbot certonly -d example.com --webroot -w /tmp
rm -rf /etc/letsencrypt/{live,archive}/example.com

then every time you run:

certbot certonly --cert-name example.com -d example.com --webroot -w /tmp

you will get a suffixed example.com-xxxx name, despite --cert-name.

This is because:

  1. When initially checking whether the certificate is a new lineage or a renewal, Certbot tries to fully reconstitute the existing lineage. If this fails (because some files are missing due to the above rm) the error is swallowed and Certbot says, "this is a new lineage".
  2. Later, when checking what certificate name to save the new lineage under, Certbot looks at whether /etc/letsencrypt/renewal/{cert_name}.conf exists. If it does, it suffixes the name, even if --cert-name was explicitly specified.

Certbot's storage is a bit vulnerable against this kind of thing if you manually move or delete things without using certbot delete.

I guess we could try align (1) and (2) so that they at least agree with each other, but I'm unsure whether it would overall have produced a better outcome in this case.

3 Likes
6

I did do some manual work after I found a new folder was created. New certs in -XXXX folder were copied to the original folder. Could you please tell me how to fix it? Thanks!

1 Like
7

Well, a rate limit prevents you issuing certificates for the next 21 hours. So I wouldn't try to fix it until then:

Rate Limit Current Status Domain
5 Duplicate Certificates per week Limit exceeded. Next issuable at 06 Apr 2022 05:49:18 UTC *.scicat.ess.eu

How it fix it would be to make sure that you fully remove all of these paths:

  • /etc/letsencrypt/renewal/*.scicat.ess.eu.conf
  • /etc/letsencrypt/archive/*.scicat.ess.eu/
  • /etc/letsencrypt/live/*.scicat.ess.eu/

Be careful. Due to you having put a * in the certificate name, you will have to escape the directory name in your shell using "quotes".

Be careful also because if your webserver relies on these paths existing, it's temporarily going to be broken. For this reason, consider backing up the contents of /etc/letsencrypt/.

Then, next time you issue the certificate, it should have the correct name. During automatic renewal or manually running the command again, it should retain the certificate name.

Once you have issued the certificate, you can then delete all the duplicates that you're not using:

certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0001"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0002"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0003"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0004"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0005"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0006"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0007"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0008"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0009"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0010"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0011"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0012"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0013"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0014"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0015"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0016"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0017"
certbot delete --non-interactive --cert-name "*.scicat.ess.eu-0018"
3 Likes
8

Thank you very much!

Let me confirm the steps:

  1. Before 06 Apr 2022 05:49:18 UTC, I shall remove all of these folders:
    /etc/letsencrypt/renewal/*.scicat.ess.eu.conf
    /etc/letsencrypt/archive/*.scicat.ess.eu/
    /etc/letsencrypt/live/*.scicat.ess.eu/
  2. After the new certificate is issued, I shall delete all of the duplicated certificates.

Is that correct?

BTW, how can I check the rate limit information?

1 Like
10

I have a tool here which you can query. It's not always accurate though, since it uses publicly available certificate data, rather than the internal Let's Encrypt database.

You should do it after this date, so you don't end up stuck.

3 Likes
11

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