High, sorry I ignored the template but this is a straight forward question.
Do I need a registered public IP on a acme-dns server in order for it to work? Or does the acme-dns server initiate the connection with acme-dns? I’d rather have a server inside my LAN with a private IP. That was partly what got me on using dns-01 and now I want to automate renewal with acme-dns-auth.py.
I was following a very simple guide on using the python script and didn’t realize I needed to setup acme-dns to register my subdomain in order for the script to work. Going down the rabbit hole…
Sorry if I’m missing any details but hopefully acme-dns can work on a server that isn’t exposed to the WAN.
You need a publicly-accessible system of some kind to answer the challenge requests from the Let’s Encrypt server. I’m assuming you’re not trying to get a certificate FOR an IP address, which Let’s Encrypt will not do as they only issue certificates for domain names. Probably the best thing you can do in your case, as long as there’s a publicly-accessible entity to answer the DNS challenge, is to use dns-01 challenges. That way your IP address and accessibility to your server are irrelevant. However, the script would need to be able to create the publicly-accessible DNS TXT records necessary for the challenge (or you would need to use some kind of “manual” mode where you can add those records yourself before proceeding to have the Let’s Encrypt server verify that the dns-01 challenges have been satisfied, which is not automated). The crux of the matter is that you need to be able to publicly prove to Let’s Encrypt that you do in fact control the domain. So long as they can see that proof by making specific inquiries to specific places, you’re good. This allows using whatever entities/forwarding you need to use.
LetsEncrypt needs to access the machine, so acme-dns needs to be exposed to the WAN/public-internet.
If you are keeping everything local and private, you could use a DNS plugin or Lexicon for your DNS provider/registrar. IMHO, acme-dns is your best option as it is much more secure (most vendor APIs offer too much control with their account tokens, so you have a lot of exposure). You could either run AcmeDNS on a machine on the public network, or open the ports on the current network to route traffic to it. AcmeDNS only needs to run during the challenge, so you can turn it on/off as needed.
I was just going to generate a wildcard for our internal servers. My employer still wants to pay for certificates for external servers. This is kind of a side project on my own time and the camel’s nose under the tent so to speak. If they like what they see maybe they’ll adopt it for external servers hehe.
I’ll figure something out for external. Maybe I can put the service on a server that is already facing the WAN rather than creating another firewall rule for this certbot server. And as far as I know we don’t have any firewall rules listening on 53 so I should be able to forward requests back to an internal server if need be.
At first I thought it would behave the same as a manual dns-01 check and I just had to copy the domain over to our DNS hosting on our provider when it paused and It would be cricket. Certainly explains my failures. Oh well. A couple of hours down the drain before I found the pertinent documentation so not too terrible.
Alright. Thanks mate. I gave a lengthier answer to the other reply.
It’s a learning experience. DNS-01 was quite easy to get going but a shame it can’t be automated. I don’t want to have to do it every three months and update our DNS TXT record on our provider site every time.
I think I addressed that in another answer. Yes, I think ideally I could add the acme-dns service to an already existing WAN facing server rather than create a new firewall rule for this server. My employer seems somewhat resistant to this, so I’m trying not to rock the boat too much. He’s happy with just buying certs once a year for each server, but I thought this looked like a fun project and could save a bit of money in the long run.
Since I’ve received a lukewarm reception I’m just plugging away in my own time and I also have a few of my own servers that could benefit. Obviously this would be ideal if it’s completely automated with cron jobs and I could just add it to our company wiki if I ever move on and someone else needs to manage it.
I’m not too familiar with your acme client, but having written my own online dns-01 acme client (freessltools.com/freesslcertificate) I can say that it should not really matter where the client is running so long as it can communicate the process with the Let’s Encrypt server (basic GET/POST). The machine running the client and the machine being DNS queried by the Let’s Encrypt server need not have anything in common (as is ALWAYS the case with my acme client). The only interconnection is if the client is trying to manage the externally-facing DNS record content, which is critical for automation. You usually want the client running on the machine utilizing the certificate though so that the private key and certificate signing request are generated there (and the resulting certificate ends up there). I’m assuming you’re having the client install the cert and key too?
For simplicity then you’ll want the client on the target machine so the cert and key end up in an accessible (and secure) place. I’m assuming you have no trouble sending and receiving basic web traffic from your target machine?
With acme-dns, you only need to manually setup the domain/dns during the INITIAL certificate provisioning – as that requires delegating the DNS records to the acme-dns server and account. Once that is set up, renewals are all automated.
The machine answering DNS needs to be publicly accessible (the acme-dns machine). The machine which will use the certificates do not need to be publicly accessible.
I handle internal developer certificates for our team like this, on my laptop:
A "preflight" script is invoked, which ssh's into a public internet server, starts the acme-dns instance, and opens up firewall traffic to it (port 53 dns and port 8*** for the REST API
Certbot is invoked to renew, using the acme-dns plugin
A "cleanup" script is invoked, which shuts off the acme-dns server and clears the firewall rules
The certs are then on my laptop, and I enroll them into source control for distribution [the private keys are encrypted in the source tree].
While this is currently 3 scripts which are manually invoked, it only requires copy/pasting from a text file... and could be done in 1 fully automated script.
Thanks for all the helpful replies. I did read up about using an API, but the big knock on that was security concerns if the API gets compromised. We use a smaller Canadian provider as well and I didn’t see it on the list of APIs in the documentation. There were a lot but not ours. I am a pretty paranoid guy and given this isn’t something that my boss was that enthused about I’d rather take the safest approach and not be liable for a security breach of our domain
Understandable. You can always do manual dns challenges through Let’s Encrypt every 60-89 days and not worry about any API concerns. You get an email reminder to renew the certificates. This is what I do with ALL of my domains. It only takes me like 5 minutes to renew a certificate.
If hosting your own acme-dns instance is too much trouble, you can effectively do the same thing by delegating the sub-domain that you would've delegated to acme-dns to another DNS provider instead...specifically one that has an API and support in the client you're using. There are plenty of free DNS providers out there for low traffic and/or low zone count users. Though not all support hosting sub-zone delegations.
I think I misinterpreted your initial post. I concur completely with your approach.