I have an architectural question about setting up Let’s Encrypt for my mail servers.
I currently have two servers on an RFC1918 subnet (192.168.x) for mail - a spam filter (ASSP) and an email server (Postfix/Courier). I currently use a cert that has 3 SANs in addition to the CN. I use the same cert (in different formats) with Courier and ASSP. Postfix does not require a cert in my configuration.
The firewall is a busybox based Linux machine (Leaf Bering uClibc).
I’d like to have one of these machines pull the certs, and then I’d script the copy of the certs to where they need to be. What is the best way to implement that? Is it possible to run Certbot on a machine sitting on a private network? If not, will Certbot run on a minimal configuration machine like Leaf?
One assumption I’m making is that the Certbot requests have to come from the public IP that matches up to the CN and to all the SANs.
The requests do not have to originate from an IP address that matches a subject name. However, with two of the three available validation methods, the requests do have to be confirmed by receiving an inbound connection on such an IP address.
That means that the client software requesting the certificate has to somehow be able to cause the correct information to be returned in response to this inbound connection, which is normally done by running the client on a server that does respond for those IP addresses, but does not inherently have to be done that way. There is a particular method involving HTTP redirections that’s pretty effective when you want to get one machine to get certificates on behalf of other machines, assuming that they can all receive inbound connections but don’t have the same IP address. However, that might not be the case for your particular situation.
If you can’t receive inbound connections from the public Internet, the easiest method might be DNS-01 authentication, where you prove your control of the domain name by making a requested change to the DNS zone. Can you update your DNS zone? Different clients can trigger this by running a script or using a DNS provider API.
Thanks for the reply. I AM able to receive inbound connections on the IP address in question (all the SANs and the CN are currently directed to the same IP and will remain so unless something changes.)
Let me run a scenario by you and let me know if you think this will work. I will run certbot on a machine on my private subnet, with port 443 forwarded to it. If I understand certbot correctly, it can start an https server for the authentication, and then shut it down when it is complete. I do not use https on this IP for anything (I’m only hosting “business card” type websites with no current need for encryption) so I can leave that port forward open. I can then script the distribution of the certs from there. Do you think that will work?
Thanks again for your help.
Forgot to mention - yes, I can update the DNS zone. I have two bind servers that I host DNS on, so that will be an option however I think that will be more labor intensive to setup.
Yes, this approach can work. If you run into any trouble, be sure to explain how you’ve done it so that the people trying to help know it involves port-forwarding. Your description sounds as though it ought to work first time and be repeatable as needed for renewals (since you mentioned leaving the forward in place).
I suggest thinking about monitoring while you’re there, so that you would be alerted if a certificate for the mail server has only say, 10 days or less until expiry, which would give you those ten days to debug the problem, whether it’s with Certbot, or your distribution scripts, or somewhere else.
Thanks! I appreciate the insight. I am going to start work on this and see how it goes. I’ll report back.
Sure, in this case you should most likely use
Indeed - I did this on a test server using --dry-run and everything looked good! Will keep you posted.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.