2023 will be here in just two short days and my mind is wandering around things related to LetsEncrypt and it’s been a bother. I vaguely remember fighting to get LetsEncrypt to work in several different installations from Docker to bare metal and some points in between. The hard part was that I always ended up back on the dns-01 challenge. For some strange reason I had allowed myself to be programmed that a DNS challenge was the only way my naked domains were going to work. Well in the last few days I had to reconsider my condition and http-01 is more than adequate.

First of all… the dns-01 challenge was intended for systems with environments that would not permit port 80. Some non-commercial ISPs block port 80 and LetsEncrypt depends on port 80. Also, the dns-01 challenge is meant for wildcard domains. I started off liking wildcard and naked domains but now; not so much.

One of my latest installations was strictly OpenBSD and in that less-is-more environment of httpd, relayd and acme; OpenBSD simply does not support dns-01 and is limited to http-01. My system has been around for a while and I never really thought about it. I know the OpenBSD devs can be quite opinionated and sometimes quite rude about it but on this subject they were pretty mum except to be clear that they only supported http-01.

And so I started down the road:

I always thought that wildcard DNS was for wildcard networks and when you enumerated the subdomains they needed to be explicit. In my wildcard domains I had always configured an A record with a “@” and a “*”. Then I provided credentials to my DNS server so that my ACME script could create the various challenge responses that LetEncrypt needed. What’s worse is that I create all my domains using one service and then change the nameserver to a different service … my domain vendor does not have API and my nameserver vendor is natively supported in ACME.

In my current OpenBSD project I’m using http-01 and so I’m using my domain vendor’s nameserver because the subdomains are named. And everything is solid. I’ve created a naked domain A record and an alias with a real subdomain and A record. (this might not makes sense… but essentially I created fully realized subdomains instead of wildcards.) And of course this worked fine and with no credentials or APIs. Just default LetsEncrypt behaviour.

Then it happened. I found myself questioning whether or not I needed realized sub domain names in DNS. Could I used wildcard DNS and then use realized sub domains in ACME.

So I …

• created a naked A record
• created a named CNAME record pointed to the same domain as the A record
• configured my httpd and relayd services with my naked and realized sub domains
• configured my ACME with the named and realized sub domains
• renewed my domains in ACME (it worked)
• loaded my home pages and checked the certs in the browser (worked)

And life was good again. What I learned was that (i) DNS is and should be isolated from LetsEncrypt/ACME for both security and latency as using the APIs have side effects. (ii) wildcards in the DNS are fine for both challenges. (iii) keep in mind most projects are chickens not cows and that long involved and complex SSL certs are not very useful. (iv) dns-01 does put corporate security at risk.

And now the secret sauce.

LetsEncrypt has a secret. It pretends to be for public services. But what do you do when you have a number of internal systems like an API server that needs SSL and self signed certs are undesireable? Using ACME and realized sub domains with wildcards in the DNS means that one can create certs for communicating internally. Simply put; the system that renews certs needs to have additional alias sub domains. The when renewing (n) subdomains will receive certs. The certs canm then be copied around the system so that the private servers can validate eachother. All without exposing your DNS credentials.

do not combine all the PEM files into a mega-all-in-one PEM file. That will fail.