Let's Encrypt HTTP challenge certs from private network

#1

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:

  1. 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).

  2. On proxy.my.domain.com go to [Port Forwarding] -> [ CREATE NEW] and

    PortForward
    PortForward.png254×644 20.8 KB

    This will forward HTTP (port 80) requests from our public IP to our internal server, allowing letsencrypt http API to reach our internal server.

  3. 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:

    ConnectionError: ('Connection aborted.', error(101, 'Network is unreachable'))
ERROR:certbot.log:An unexpected error occurred:

    I’m still trying to know why this happend, running:

    # /usr/libexec/nethserver/letsencrypt-certs -v -e informatica@durerocaribe.cu -t -d ratatosk.durerocaribe.cu

    Returns …

     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:

    # /usr/libexec/nethserver/letsencrypt-certs -v -e informatica@durerocaribe.cu -t -d ratatosk.durerocaribe.cu

    @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.

Missing proxy enviroment variables
#2

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)
1 Like
#3

There are other ways of getting Let’s Encrypt certs:
https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_for_internal_servers
https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_acme-dns

2 Likes
#4

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?

#5

Those are great solutions, but:

  • 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.
  • Let’s Encrypt and acme-dns (or, wildcard certificates with any DNS provider) requires that you can manage your own domain, if your DNS provider doesn’t allow you this then you this solution won’t work.
    With @davidep suggestion you only need to:
  • Ask your DNS provider to create several A records on your DNS
  • On your firewall/gateway/proxy server, request a new Let’s Encrypt certificate and include all your internal servers.
  • Extend the certificate-update event.

This is another way of getting a signed certificate for those constricted by a DNS provider.

#6

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.

1 Like
#7

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.

#8
  1. configure pubkey authentication on all your internal hosts, so that you can scp a file from the firewall to them without password prompt
  2. prepare an executable script that copies the PEM files from the firewall to each internal host, then restarts/reloads its services properly
  3. in the firewall, install the executable script above as /etc/e-smith/events/certificate-update/S80push_certs
  4. add /etc/e-smith/events/certificate-update/S80push_certs to /etc/backup-config.d/custom.include

If it works, please write an #howto :wink:

1 Like
#9

Oh yes, please @jfernandez do it. If you need help I’m here.

1 Like
#10

4 posts were split to a new topic: Let’s encrypt certs for internal hosts with HTTP challenge