Two wildcard certs that flip-flop back and forth

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. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: sudo certbot certonly --manual --manual-public-ip-logging-ok --preferred-challenges dns-01 --server -d "*" -d

It produced this output:


  • Congratulations! Your certificate and chain have been saved at:
    Your key file has been saved at:
    Your cert will expire on 2021-08-25. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    "certbot renew"

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let's Encrypt:
    Donating to EFF:

My web server is (include version): apache 2.4.29 64-bit

The operating system my web server runs on is (include version): Ubuntu 18.04

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

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

I have a wildcard cert that seems to flip-flop back and forth between two directories every time I renew them.

One directory just has the name and the other is . When my apache config is set to use, when I renew the wildcard cert, it renews . Then I configure apache to use the -0001 directory, and when I renew it, it renews. the directory.

How do I get rid of the -0001 directory and just have one directory for my wildcard cert?

Also, when I try to add the Nextcloud server for my calendar and contacts, it tells me the cert expired back in 2018. But when I check it form my Mac, Windows or Linux machines, it shows a valid cert that expires in July.


You could use --cert-name with your other certbot options. That would make sure it won't generate those other pesky -0001 certificates.


Can I delete the -0001 cert?


If you're sure your other certificate is perfectly fine and your services aren't using the -0001 cert any longer: yes.


Will that keep it from coming back, or will I always need to use the --cert-name option?


Probably not, as you had the issue with the -0001 cert before too. That said, the version of certbot you're using is quite old and there probably have been made many improvements which includes the handeling of certificates. Older versions of certbot had the -0001 issue a lot, but more recent versions don't generate -0001 or -0002 et cetera certificates that often any more. If you could upgrade your certbot version, you'd probably be OK.

If not, just use the --cert-name option. You're already forced to use the full command for each renewal anyway due to the fact you're using the manual plugin without a manual-auth-hook, so an extra command line option isn't that much trouble I recon.

By the way, I'm seeing your DNS provider is EasyDNS. They offer an API for the manipulation of DNS zones. Unfortunately, certbot itself doesn't have a DNS plugin to handle that API, but the client does:

I wouldn't recommend switching from certbot to, although that is of course an option. However, you might be able to use the code in the script above to modify it so it can be used as a certbot hook in --manual-auth-hook and --manual-cleanup-hook.


You should look in the renewal configs - one of them is likely keyed to creating the -0001 directory. If one is, it will continue to make them. You can likely audit the renewal configs and decide which to keep and which to delete. Fixing the renewal config files should fix your issue.


@jvanasco Deleting a certificate through certbot delete also deletes the renewal configuration file. So if one would delete the -0001 cert, all references to directories containing -0001 would be gone too.

Unless one has manually tampered with the renewal configuration files of course :stuck_out_tongue:


I guess. IMHO the entire bit of certbot that generates those has been a bit unpredictable, and I just fix it manually. Like a honeybadger.


Exactamundo! :100:

This is spot on. I also agree with @Osiris's sentiment here. A good firebombing (after proper analysis and detangling the configuration web) is likely in order. :bomb:

I never perceived a honey badger as a mechanic. :thinking: Then again, its approach is probably pretty apt in some of these scenarios. I find anymore that I tend to initially ask almost everyone seeking help for a recursive dump of the entire /etc/letsencrypt folder. Figure I should just assume there's something wrong in there.

1 Like

In this case I believe it's simply an older version of certbot which still had all that quirky behaviour with those double or even triple copies of certificates with those pesky suffixes, which is fixed in more recent versions. Not sure which version though.


In many of the situations I've encountered with those suffixes, manual and/or explicit certbot copying has been at play. Roping down the existing certificates and making sure there isn't cross-contamination between certificate folders ("lineages"?) is likely in order. Scalpel! :hocho:

On a related side-note, certbot sometimes drives me crazy with its "overintelligence" in identifying "matching" certificates. Sometimes its just easier to create a "clean lineage" then blast the mess.

1 Like

Not a mechanic. The honeybadger doesn't give a ****. See


The original concept (something that probably should have had a slightly different user interface) was this:

  • If the names are identical, you get a renewal (same lineage, same name coverage)

  • If you have no overlap between the old and new names, you get a totally separate certificate

  • If the new names are a strict superset of the old names, you get an expanded certificate (same lineage, new name coverage)

  • If the new names overlap the old names in some other way, you get an -0001 certificate.

(Prior to the introduction of --cert-name, there was no way to remove a name from a certificate's coverage with Certbot at all; there is still no way to do this without using --cert-name.) One of the things that most confused people is that --expand doesn't mean "try harder to find a relevant certificate to expand", it just means "if you find a certificate for which these names are a strict superset, expand it instead of asking whether to expand it as opposed to making a duplicate certificate". I think this behavior was subsequently made the default. Probably a lot of the -0001s that people get come from thinking that --expand will find the "most overlapping" existing certificate and add specified names, or update it to replace the name coverage, or something. But it never does that.


Thanks for clarifying those, @schoen. :slightly_smiling_face:

It's mostly what I thought.

1 Like

Ok. I went in and manually edited all my apache config files to remove any reference to the -0001 cert.

Then I ran:

sudo certbot revoke --reason superseded --delete-after-revoke --cert-name

I realize that the version of certbot I am running is very old. The "server" in my house is running Ubuntu 18.04. I'm plannng to upgrade to Ubuntu 20.04 this weekend. That should give me a newer version of certbot, since I am sure the 20.04 repository will have a more up-to-date version.


You want to avoid certificate revocation unless absolutely necessary.

1 Like

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