So far this is what I did to get a Let’s Encrypt certificate, for this example I’m using internal.my.domain.com as the internal server FQDN and proxy.my.domain.com as the gateway/proxy server FQDN. Using the web UI:
On internal.my.domain.com go to [Network Services] → [ httpd] → [Edit] and allow the red interface. This also can be accomplish by creating a firewall rule (Allow port 80 from red interface to firewall), but it would be necessary to install the Firewall Base module. It’s necessary to do this since we will receiving requests from internet (letsencrypt http API).
On proxy.my.domain.com go to [Port Forwarding] → [ CREATE NEW] and
This will forward HTTP (port 80) requests from our public IP to our internal server, allowing letsencrypt http API to reach our internal server.
On internal.my.domain.com go to [ Server certificate] → [ Request a new Let’s Encrypt certificate] → [ REQUEST LET’S ENCRYPT CERTIFICATE], on this step you will get this error:
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/ratatosk.durerocaribe.cu/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/ratatosk.durerocaribe.cu/privkey.pem
Your cert will expire on 2019-09-26. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
Restoring /etc/letsencrypt/ ...
I don’t know what happens when you hit [ REQUEST LET’S ENCRYPT CERTIFICATE] button, except that this command is ran:
@davidep could you please help me? The only way to go around this is by setting a firewall rule on the gateway/proxy server allowing internal.my.domain.com to red interface over HTTP. Only then I get a certificate. Also, this solution only works when you have only 1 internal server, for 2 or more it would be necessary to maybe set up a reverse proxy, but I haven’t find a way to properly do it.
Also, I think we might need to create a new thread for this situation, but I would leave this decision to a moderator.
If you run that command as root, you receive the environment variables for the proxy setup and works. I’m afraid the same command run by server-manager does not see the same environment thus it fails.
You could try to configure LE on your firewall with all the system names you need. Then configure reverse proxy to your internal hosts.
For certificates in internal hosts there are some alternatives
use http, no certificate at all
use https, certificate self-signed and ignore cert errors from the reverse-proxy
push the certificate to internal hosts with scp when certbot renews it on the firewall. You can drop an action in the certificate-update event (thanks to @Amygos for the idea)
I like this as a solution, as it offer the following:
Internals servers can stay behind the proxy (Since currently Let’s Encrypt certificates challenge can’t get through the proxy) and still get a signed certificate for secure connections, which is required for a lot of apps, specially those developed on Java and C#.
You don’t need to incur in extra configurations (using reverse proxy), instead you extend a script.
That being said, @davidep and @Amygos, could you give the details for accomplishing this?
Let’s Encrypt for Internal Servers requires a DNS hosts supporting the ACME API, if your DNS provider doesn’t have a supported API, this solution won’t work.
To be clear on this, the DNS host doesn’t have to know anything about ACME, but they do need to have an API that supports automated updates to your records. Lots of providers have this, but certainly not all of them (at last count, acme.sh supported about 50 different APIs).
Well, it requires that you be able to make a few static DNS records. The advantage of this method over the previous one is that it doesn’t require any automated updates to those records; they stay fixed, while your local acme-dns installation acts as the nameserver for the stuff that does need to change. If your DNS provider won’t let you make the records that would be necessary, it might be worth considering using a different provider. But in any event, I was just wanting to point out that there are some other methods available for obtaining a cert for an internal server–everyone’s situation is different, so they may not be suitable for you.
I agree with you, thanks to your last reply, people have a resumed explanation about which solution suits their needs. Adding up @davidep suggestion we will have another one, this is way I love NS community.
