Can Lets Encrypt be automated without outbound HTTPS access?


#1

For security reasons we have web servers that don’t have unrestricted outbound access (with unrestricted inbound HTTPS in this case) and while we can whitelist specific IP addresses Lets Encrypt has stated multiple times that they may change their IPs at any point, meaning that isn’t an option.

I’m currently using a cert generated manually on a non-secured system using DNS verification, which is great for the next 90 days and an annoying pain to constantly redo after that.

Is there any way to automate Lets Encrypt in this situation without poking a giant outbound hole in our firewall?


#2

I’ve only seen that advice strongly put forward for inbound (validation server) connections.

I see no reason why you can’t pin the IP address of the ACME endpoint on your system’s /etc/hosts. If it does change, you will have sufficient notice that your certificate is expiring, and I don’t foresee a huge security issue either, since it it all happens over HTTPS anyway.

Other than that, you could also automate the process on a separate (internal) host, copying the HTTP-01 validation file across in a manual auth hook as required, and write a deploy hook to install the certificate to the secured host?


#3

Still, the web services currently use CDN services from Akamai, who, as far as I know, have a similar policy about not documenting their (extensive) IP ranges.

https://community.akamai.com/thread/6501-ipsubnet-information-of-all-akamai-edge-server-lists

I don’t know how sticky they usually are in practice, though.

(And of course Let’s Encrypt provides no guarantee they’ll even continue using Akamai!)


#4

…or similarly use DNS validation on a separate internal host, and then deploy the cert/key files to the appropriate machine.


#5

What issues are you having with the DNS verification? Is it the verification process itself, or distributing the certificates into the secured servers? I can think of many automated shortcuts to deal with getting the verification done, but they’ll all share issues with the certificate distribution.

If the issue is in certificate distribution, you might be able to use SSH tunnels (if that traffic is allowed). You could create a SSH tunnel into a non-firewalled machine, and send the certbot traffic (or whatever client) through it. You could script things so the tunnel only wraps the certbot process while it runs.

If the issue isn’t in certificate distribution, some ideas are above.


#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.