Yes, I don't think Certbot is very well-optimized for that. For example, there's no option to request a certificate to be saved in the current working directory, except with --csr, so you can't do that if you don't have or don't want to use a CSR file.
Certbot is most optimized around doing its own automated renewals with its own web server integrations or with mostly-Certbot-provided authenticators and plugins that handle certain other cases well.
But why? Sure, domains you no longer control can be taken care of with certbot delete. But so what if it keeps old files around? All of the files for a cert put together (cert, chain, fullchain, privkey) consume less than 10 KB of space. They renew, by default, 6x/yr. That means that, for every cert you have, it will grow by about 60 KB/yr. I don't really see value in keeping the old files 99% of the time, but I also don't see that there's a strong reason not to.
Really, it seems like the confusion goes away if you treat the /etc/letsencrypt directory as a black box. If you want to act on the certificate files directly, certbot (or many other clients) is perfectly capable of saving a copy of them somewhere else.
I'm 99% sure that's exactly what @jessuppi wants to avoid.
I think you're right, but that just leads to the question of "why use certbot, then"? Because that's the way it's designed to work. It's really looking like:
and it'd be much better to use a different client for this application. It's not like there aren't a lot to choose from.
Personally, I would find it flattering if such loyalty were shown to my software that system administrators would openly request to better understand it in order to fully integrate it into their systems. Granted, certbot is open source, but having absolutely lucid documentation of functionality, especially of such a significant endeavor, only serves to strengthen both the development and deployment efforts of certbot. Having utilized and written such documentation while working in R&D on commercial electronics and embedded test devices for telecom, I fully understand the intensity of resources and monotony involved. Multiple-thousand page functional specifications stemming into various manuals and wikis can certainly be daunting.
...and I'm probably on the opposite end of things, in that I'm not much of a fan of certbot at all--it's far too big, with far too many dependencies, for what it needs to do (if acme.sh had the acme-dns integration script that certbot does, I'd probably never use certbot). So I may be much more ready to suggest an alternate client than some would be.
I hear ya there for sure. To avoid the dependency issue for my own client (written in PHP), one of my fundamental design requirements was to only utilize the functionality of the most basic set of proven libraries included with the default configuration of GoDaddy shared hosting. We're talking things like OpenSSL and cURL here. I haven't dug into the guts of acme.sh, but I would much imagine a similar set of basics.
Out of curiosity, what is lacking from acme.sh's existing acme-dns script? dnsapi · acmesh-official/acme.sh Wiki · GitHub
.acme.sh/account.conf, which makes me believe it can only handle one set of credentials. If that's correct, it means that a given acme.sh installation can only issue certs for a single FQDN using acme-dns--no multi-SAN certs, and really only a single cert. If that's not correct, the docs are badly in need of an update--which they are in any event.To use acme.sh with acme-dns, I must obtain a set of credentials (curl -s -X POST https://auth.acme-dns.io/register | python -m json.tool), create the appropriate CNAME record, export the credentials into the appropriate environment variables, and then call acme.sh. Lots of manual work, and as noted above, it can only handle one FQDN per acme.sh installation.
By contrast, with certbot and @joohoi's hook script, I call certbot and tell it to use that script. The script checks the requested domain(s) against the credentials issued previously; if it/they already exist, it's assumed the CNAME records are present, loads the relevant credentials, and goes to town--all without user interaction. If it doesn't have a set of credentials matching one or more domains, it obtains them, stores them, and prompts you to create the appropriate CNAME record(s). Creating the CNAME is the only user interaction needed with acme-dns in this case. Multiple certs, multi-SAN certs, wildcards, are all handled easily.
Thanks for the detailed explanation. I didn't realize the acme.sh implementation was so limited. Not that it necessarily helps your situation, but Posh-ACME's acme-dns implementation works very much like the certbot hook script. Everything is automated except the prompt to create the initial CNAMEs.
I agree, acme.sh should manage multiple credentials for the same dns plugin, I hope someone can add it to acme.sh but just in case, sometimes I've used this to be able to use 2 or more credentials for the same plugin... I know this is dirty as hell but...
cd /root/.acme.sh/
cp dnsapi/dns_acmedns.sh dns_acmedns01.sh
sed -i 's/dns_acmedns/dns_acmedns01/g' dns_acmedns01.sh
sed -i 's/ACMEDNS_/ACMEDNS01_/g' dns_acmedns01.sh
Now issue your cert:
export ACMEDNS01_UPDATE_URL="https://auth.acme-dns.io/update"
export ACMEDNS01_USERNAME="<username>"
export ACMEDNS01_PASSWORD="<password>"
export ACMEDNS01_SUBDOMAIN="<subdomain>"
acme.sh --issue --dns dns_acmedns01 -d example.com -d www.example.com
I know, it is not the best approach but could save your ass in some situations 
Edit: I forgot to say that you can also specify a different --config-home parameter, this way you don't need to modify the dns plugin but you must use always the --config-home in all your commands and create a new cron entry.
Cheers,
sahsanu
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.