Based on what I posted back in this thread Prevent -0001 -xxxx Certificate Suffixes, I have been using the --cert-name option when running certbot via a web control panel I develop like so:
"--cert-name " . $firstDomainInList
Unfortunately, even with that parameter, I saw a new folder created with the “-0001” suffix. My understanding was that if the certificate exists with that name, it is supposed to be updated. I ended up with two different certificates (the old one with the right name, and the new one with a suffix). This messed up things because the control panel software expects the path of the certificate to not use a suffix.
So, should I be using more than this parameter to make sure it always writes the certificate in the specified folder even if it exists? I see some options here in the documentation: https://certbot.eff.org/docs/using.html
They mention --force-renewal , --duplicate , and --expand options.
Do I need to be using a combination of the two? Appreciate any help on this.
I haven’t checked the code, but I’m guessing Certbot might have disregarded the specified certificate name because that certificate was broken:
2019-01-22 23:48:16,081:DEBUG:certbot.cert_manager:Renewal conf file /etc/letsencrypt/renewal/entry3.mydomain.com.conf is broken.
2019-01-22 23:48:16,103:DEBUG:certbot.cert_manager:Traceback was:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/cert_manager.py", line 114, in lineage_for_certname
return storage.RenewableCert(renewal_file, cli_config)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/storage.py", line 461, in __init__
self._check_symlinks()
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/storage.py", line 520, in _check_symlinks
"expected {0} to be a symlink".format(link))
CertStorageError: expected /etc/letsencrypt/live/entry3.mydomain.com/cert.pem to be a symlink
Do you know how that could’ve happened? Do you have custom code to rename, delete or otherwise modify certificates?
Actually, yes, the control panel deletes the old certificate files if it detects the domain list has changed before calling certbot to get a new one. I guess I wouldn’t have to do that anymore, but certbot should still not freak out about that and respect the --cert-name parameter when trying to get or renew certificates - even in the rare case that they are broken or no longer exist.
The deletion code I use removes files from these locations
/etc/letsencrypt/live/
/etc/letsencrypt/archive/
I’m assuming if I removed the .conf files in the renewal directory of /etc/letsencrypt/renewal/ as well that would be sufficient to work around this issue? I still think certbot should go with the provided --cert-name parameter no matter what it runs into for storing new certs.
It’s respected if everything doesn’t exist – if the archive and live subdirectories and the renewal configuration file don’t exist – like if you use “certbot delete” – Certbot will have no idea the certificate ever existed. But if something’s partially deleted, that’s the same as being broken. And Certbot doesn’t always handle corrupt data in the most user-friendly ways.
I just updated my last post stating almost exactly the same thing. I will delete the conf files as well in the control panel code, but I still believe if things partially exist, --cert-name should still work too.
True, but how Certbot manages its internal state is a private behavior and could change without notice. Seems akin to relying on undefined behavior.
So while it is probably a bug and you could file an issue to get it fixed, you have the alternative of a stable public interface that already does what you want:
I agree, that is the better approach. I’ll use that instead. However, I still think the behavior of certbot is wrong when things are not as they should be.
