I’m currently using LetsEncrypt successfully to generate certificates for a variety of services, but for the most part it is a manual process. I’m looking for advice on what I would need to change in my environment to help automate the process. My apologies in advance if I’m rough around the edges in explaining my setup.
I have multiple domains. Some have their DNS managed at the registrar (Google Domains, Network Solutions, GoDaddy) and some have their DNS managed at our web servers (cPanel/WHM).
LetsEncrypt certs are fully automated for our websites (example.com and www.example.com) on cPanel/WHM. Set and forget, no problems at all.
We have ACMESharp Powershell scripts that handle some of the renewal processes but we still need to do the DNS challenge manually on every single renewal. From what I understand this is due to the short DNS challenge authorization validity period.
I’ve looking for a way to update the TXT record programmatically from within my PowerShell scripts but I’m a bit out of my element and have come up empty.
What I’m looking for is advice on what I should be looking to change so I can easily automate the renewal process for a variety of my disparate services. I’m also aware that actually installing the certificate might still require manual intervention (ie sonicwall), which is fine.
This does depend on who the DNS hosts for each domain are, because each provider may (or may not) offer an API, with a different interface and presumably different credentials, to update records programmatically.
An increasing number of Let's Encrypt clients have support for doing this from software and/or calling an external script, but in each case the details depend on the particular DNS provider hosting the domain's DNS zone, and on what APIs that provider offers to handle these updates.
If you do have any DNS zone that you can update programmatically from a renewal script, there's a cool trick that you can use to use that zone for all of the hostnames. This is based on setting a CNAME record for the _acme-challenge record under each name that you care about to some corresponding record in a different zone. For example, you could set _acme-challenge.sonicwall.example.com. IN CNAME sonicwall-challenge.easier-to-update-otherdomain.com. and after doing so, you can complete a Let's Encrypt DNS-01 challenge for sonicwall.example.com by placing a TXT record at sonicwall-challenge.easier-to-update-otherdomain.com.
Also, starting at the end of this month, Let's Encrypt will offer wildcard certificates. In that case if you have an appropriate ACMEv2-compatible client and you can do an appropriate DNS validation to prove your control, you can get a certificate that will be valid for all of these names.
Thanks so much for your answer! I was not aware about the CNAME trickery, which is promising if I can get the other pieces of the puzzle to fit.
I’ve been in the process of migrating my domain registrar over to Google Domains for a variety of reasons. To your knowledge is there any way to script DNS TXT record updates to Google Domains? My Google Fu is coming up short on this mainly because the search terms are very noisy with unrelated topics like Dynamic DNS updates. I was hoping to be able to do this with GDomains or cPanel/WHM as they are solutions I already have in play and would be convenient to leverage, but I’m striking out.
I'm not very familiar with Windows clients, but I think the broadest DNS API support overall is found in acme.sh, which can run on Windows with Cygwin.
I didn't see a specific entry for Google Domains, but according to
If letsencrypt is going to honor/follow those cnames, has any consideration been given to allowing a DNS TXT record to delegate approval to a specific hostname for HTTP challenges?
Our use case:
we need internal certificates issued for dev.example.com, which usually point to 127.0.0.1 and are used for local development and full-stack integrated tests before app deployments
our DNS vendor is not supported by any ACME clients for API access
the monthly updating routine is:
change dns to public server
run letsencrypt
change dns back
distribute new test certificates
if we were able to simply set DNS once for letsencrypt to use a specific hostname for HTTP challenges, it would cut this workload down by 90%
You can achieve the same thing with an HTTP 301 redirect, which the CA will also follow, including to a different hostname—assuming that there is an HTTP listener on port 80 on each machine.
[quote=“schoen, post:6, topic:52669”]
You can achieve the same thing with an HTTP 301 redirect, which the CA will also follow, including to a different hostname—assuming that there is an HTTP listener on port 80 on each machine.[/quote]
The DNS for the hostnames aren’t on the public internet (127.0.0.1 or a LAN IP behind the office firewall) as they servers/certificates are only used for internal development and integrated tests.
Under the current LetsEncrypt system, we need to update the DNS settings no matter what (HTTP tests need to see a public server; DNS tests need the auth code). This approach is only slightly less annoying than running a local DNS service to remap the test domains to local ips.
The pie-in-the-sky (and unlikely, I know - but I have to ask!) solution would allow us to edit DNS once to create a ‘follow/proxy’ record for LetsEncrypt instructing it to HTTP auth on a particular public facing domain we control, and then run the challenges off that public available HTTP server.
@jsha, do you think LE might have any interest in a DNS record that allows people to delete a different host to receive HTTP-01 validation connections? It seems like it would only be useful in relatively unusual situations.
@jvanasco, I think the most recommended approach is to set these CNAMEs, because you can point them at any DNS host that you want, including one that has appropriate API support to let you automate the issuance and renewal process. You don’t need an API for someone else’s DNS service, just an API for any DNS service of your choice.
@jvanasco, I think a much better and safer system for your use case would be to have a script on each developer’s machine that generates and installs a locally trusted certificate for localhost, or any other alias you choose. I discuss this topic here: https://letsencrypt.org/docs/certificates-for-localhost/.
@jsha, I think some browsers’ behavior has also become a bit friendlier to http://localhost/ origins since you wrote that—have you looked into these changes? I had a discussion about this with one software developer who had been shipping a private key with an application. It was eventually possible to switch over to just using http://localhost/ due to browser behavior changes, without losing application functionality.
You mean localhost vs 127.0.0.1? Yeah, I think Chrome may have landed some changes very very recently but AFAIK not Firefox, and I’m not sure Chrome has shipped the change yet.
If your previous conversation is public I’d be interested to read it.
That approach works well for general development (it was used, and is often still used by my team) but doesn’t work for full-stack integrated tests which must be run locally on some commits and on the main testing/source control server [I would sayd CI, but it’s manually triggered].
We’ve had issues in the past where a specific client didn’t trust a certificate (or someone screwed up the cert-pairing on the ssl termination’s config file), so now have tests that closely emulate the full production stack. A big plus for adopting LE on this particular project was easily being able to have certs on the internal test environment signed by the same CA as production. That may sound silly in many contexts, but we’re ensuring support for a lot of random OS versions, and devices with embedded browsers (which can be “Wonky AF” depending on the container app+device combo) – and this aggressive emulation/testing approach has caught a lot of issues before a commit leaves a developer’s team. Our options to accomplish this are either using a domain pointed at the loopback IP or running a DNS proxy.
To partially ease some concerns:
Everyone involved with using one of these certs has admin access on the server, so they are within a privacy oriented group, and that number of people is small.
No way in hell I’d allow a wildcard cert or topline name to be used for this. Everything is locked down to specific domains, which are either random strings or clearly labeled as development.
EDIT: I missed that you referenced the dynamic DNS API, but that only allows you to set A and AAAA records. So I guess it would be more accurate to say that Google Domains’ limited API is not useful for DNS validation.
️