According to Seth from letsencrypt, the TXT string will need to be changed each time certbot needs to renew, which is why having a plugin for your domain host provider is a good thing to have, so that the TXT field update can be automated as well.
That is why I was asking the question. We have installed LetsEncrypt manually and know the txt file changes for each install/renew. Works great as a once off. It is the renewal's that we would want automated.
Wanting to understand so that I know how to implement the right process approach a solution.
Thanks
You would need to have a DNS hosting service that either 1. is supported by the letsencrypt dns plugins 2. has an API that allows you to change TXT records programmatically. Not many consumer-level services do.
Assuming you find a service that does, you would need to use the script hooks that will take the parameters from certbot, set the TXT record, then let certbot finish the DNS-challenge
Would mean we would need to use one of the listed DNS management systems. Will need to consider this as not as simple as moving.
Thanks for reply
If you are using tinydns running on the same server as Apache, the following works well for me. This assumes you already have a virtual host already configured for your domain. This is on Centos 7.
I have logged into my server, via ssh, as myloginusername, then su root. (Of course, for security, ssh is configured to not allow ssh connection as root.)
On command line
certbot certonly -d example.com -d *.example.com
In /etc/letsencrypt/cli.ini
manual
server = https://acme-v02.api.letsencrypt.org/directory
rsa-key-size = 4096
preferred-challenges = dns
manual-auth-hook = /path/to/certbot-dns-auth.sh
manual-cleanup-hook = /path/to/certbot-dns-auth-cleanup.sh
In certbot-dns-auth.sh
#!/bin/bash
cd /etc/tinydns/root
cp -f data data-good
echo "'_acme-challenge.$CERTBOT_DOMAIN:$CERTBOT_VALIDATION:120" >> data
./update.sh
# Sleep to make sure the change has time to propagate over to DNS
sleep 25
In certbot-dns-auth-cleanup.sh
#!/bin/bash
cd /etc/tinydns/root
head -n -1 data > tmp; mv -f tmp data
./update.sh
Note: I have tinydns running on a second server. The file update.sh in /etc/tinydns/root is a bash script that runs âmakeâ to update the data.cdb file, and uses rsync to copy data and data.cdb to the other server. How to do that is another topic. (If requested, I can upload detailed instructions on how to set it up.) If you are only concerned with the one instance of tinydns, replace â./update.shâ with âmakeâ
However, for interestâs sake, here is the content of update.sh
#!/bin/sh
make
rsync -avz -e "ssh -i /home/fredmc/rsync_key/ws1-rsync-key" /etc/tinydns/root/data.cdb myloginname@ws2:/etc/tinydns/root
rsync -avz -e "ssh -i /home/fredmc/rsync_key/ws1-rsync-key" /etc/tinydns/root/data myloginname@ws2:/etc/tinydns/root
I have the IP address of ws2 in /etc/hosts
I tried using -i apache to have the Apache plugin install the certificates, but it didnât do anything that I can find.
I had to manually update my Apache virtual host entries. I keep a separate file for each virtual host. This is what it looks like after my update:
<VirtualHost *:80>
ServerAdmin webmaster@example.com
DocumentRoot /path/to/http/www
ServerName example.com
ServerAlias *.example.com
# To automatically redirect to HTTPS
RewriteEngine on
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin webmaster@example.com
DocumentRoot /path/to/http/www
ServerName example.com
ServerAlias *.example.com
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem
</VirtualHost>
</IfModule>
You probably have other lines in these entries.
This is for Apache < 2.4.8.
For Apache >= 2.4.8 change the lines starting with SSLCertificate⌠to
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
Do not include SLCertificateChainFile
The files update.sh, certbot-dns-auth.sh, and certbot-dns-auth-cleanup.sh must be executable.
I hope this helps someone.
What?
That is backdoor marketing for DNS they support. And since LE is effectively the only free certificate (was DNS before edit, mental freudian slip) provider...
ugly and infuriating.
So essentially you're forced to use expensive DNS providers.
Might as well pay for a proper cert then.
Seriously why would you do that?
Why isn't one TXT record enough to verify the validity of your claim?
And I mean why do you need to change the content of this TXT record every time you renew?
I just KNEW it was too good to be true. Free certs. Yeah. Pipe dream.
The requirement to continually demonstrate control of the domain is the only way to deal with automated issuance in a safe way.
ALL CAs have this requirement, because it's baked into the common rules they have to follow. Both paid and free CAs (AlwaysOnSSL is another free provider you can check out) are subject to this.
There are plenty of reputable free DNS hosting providers that provide API control. You are also welcome to hook your own scripts to update your DNS records at any provider, not just using the ones listed in Certbot or Lexicon or wherever.
2 Likes
Thanks Fred,
Managed to get wildcard cert on our staging /testing environment through manual We had previously installed ACME V1, but found we needed to revoke those certs before we could use the the new ACME v2 and wildcard.
This is the command that worked for us
certbot certonly --agree-tos --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory -d *.example.com
We cannot automate the renewals with our current DNS as they do not support API to allow management of TXT files...etc required the auto renewal process. So will need to consider one of the supported options moving forward. Renewing one of two domains is ok short term.
LE creates domain name reference files in the Live directory EG "example.com". On renewal does it create a new reference file or updates the existing reference file? Does it create a "example.com-0001"
Well, Cloudflare provides DNS hosting at no cost, and has a well-supported API. So much for that argument.
You can get example.com-0001 if you request a certificate with overlapping domain name coverage under some circumstances. Most of the time this behavior is not quite what people wanted and maybe we should have been more cautious about it. (Most often, it occurs if you request a new certificate that lacks coverage for at least one name that was part of the prior certificate, without specifying via --cert-name that the new certificate is meant as a replacement for the previous one.)
Normally, renewals will cause new files to be saved in /etc/letsencrypt/archive/example.com and the symbolic links in /etc/letsencrypt/live/example.com to be updated to point to those files. So, if you use the names in /etc/letsencrypt/live in your server configuration, you won't have to change that configuration in response to the renewal. The original file names and paths will point to the versions corresponding to the renewed certificate.
Revoking it shouldn't have been necessary. Deleting it... also shouldn't be necessary, but may be convenient.
Thanks That makes a lot of sense. For our staging/testing not a big issue and we have documented in our doc area. Good knowledge as we deploy to productionâŚ
Thanks for the reply and explanation
Not sure why I got the error and only appeared to work after we removed...! May have done something in that did not make it work the first time. Why we are testing on our staging site.
Thanks for the reply
Amazing!!
Itâs so easy man 
Just one note: when you issue a wildcard cert
sudo ./certbot-auto certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns -d *.musicdemons.com -d musicdemons.com
First write the wildcard and next the base domain. You HAVE to write the base domain as well otherwise the base domain will error.
If you switch them, all domains/subdomains will work, but the webbrowser will only display the base-domain on the certificate.
First wildcard, next base-domain will display it correctly *.musicdemons.com
I hope that other certificate authorities will now realise theyâve been filling their pockets for many years and will now have a very hard time keeping their heads up.
May Letâs Encrypt live long. Thanks for this amazing initiative.
I just have one question concerning renewal. Will we have to issue
certbot-auto or certbot-auto renew
again each 3 months? (not that itâs much of a hassle, but just for informationâŚ)
You'll have to renew the certificate every three months. Normally we recommend that you run certbot-auto renew twice a day, every day, from a cron job. certbot renew only tries to renew certificates that are less than 30 days from expiry, so most of the time it will take no action at all.
However, certbot-auto renew is unable to renew certificates that were issued with --manual because those require manual intervention in order to renew. So, you should re-run the complete certonly command again (or investigate a way to automate the issuance process with a DNS authenticator plugin or authentication hook script).
4 posts were split to a new topic: DNS-01 Wildcard Policy Feedback
For the new wildcard domain support⌠I do something like:
$cmd = â/opt/certbot/certbot-auto --server {$SERVER}
âcert-name {$domain}
-d *.{$domain}
-d {$domain}
âemail {$email}
âpreferred-challenges dns-01
âkeep-until-expiring
âreinstall
âagree-tos
âmanual
âmanual-public-ip-logging-ok
âmanual-auth-hook my_authhook.sh
certonlyâ;
to get my certs. This is in a script and there is no user input required.
I end up with ( on testing )
Waiting for verificationâŚ
Cleaning up challenges
IMPORTANT NOTES:
- The dry run was successful.
Prior to doing the wildcard txt stuff. I would renew my domains using something like:
$cmd = â/opt/certbot/certbot-auto renewâ;
and it would renew all of the certs from my /etc/letsencrypt directory.
Since I am doing the wildcard txt entries now with:
âmanual
âmanual-public-ip-logging-ok
âmanual-auth-hook my_authhook.sh
can I still do
certbot-auto renew
or can I / should I do
certbot-auto
âmanual
âmanual-public-ip-logging-ok
âmanual-auth-hook my_authhook.sh
renew
to still do everything automatically? I have 100+ domains and donât want to have to do anything manually.
Thanks - jack
@jacksnodgrass When youâre using --manual-auth-hook, you can use âcertbot-auto renewâ. The manual auth hook command is remembered in the renewal configuration file and will be executed (non-interactively) when itâs renewing.
Thanks for the info. That is excellent news.
Donât want to hijack the thread and I think this question is mostly related⌠there is a cleanup hook:
âmanual-cleanup-hook
Are we supposed to use this to REMOVE / DELETE the DNS TXT records what we add to verify the domain with this hook. I assume so⌠but want to double check. I donât want to validate the wild card cert and then remove the DNS TXT keys that it used and have my cert invalidated.
Some sites ( google ) that have you add DNS TXT records want them to stay around. Just making sure that the Letsencrypt auth records can be removed when the script completes.
Thanks - jack