Using LE certs in proxy and VM hosts

I’m trying to understand the best way of using LE certs for a development infrastructure environment I’m trying to set up. I have a few “client” VMs on my development system that need to talk to other “server” VMs (also on my dev system) and those servers need to have LE certs installed upon them (openssl libs throw tizzy fit if self-signed and I’m trying to mimick the live environment as closely as possible).

I believe that the only way of doing this is to have one VM (“proxy”) set up in my VM environment with a bridged network to my LAN so that my router can port forward 443 requests to that proxy. (This also gives me the advantage of having external clients check into my servers too). That proxy I’ll use nginx for. The servers will be running Apache.

My ISP blocks port 80 so I’m using a DDNS provider and I’m able to generate a cert for my proxy using the DNS-01 challenge. It’s at this stage I feel as if I’ve come to a crossroad on how to proceed…

  1. Does the proxy need to also hold the wildcard for all the hosts that it will be proxying for? (need to look for the proxying commands set up within nginx to accept the HTTPS request for any internal host and then forward that request, still using HTTPS to the individual servers)
  2. The servers also need to host the certificates for their own (individual) FQDNs correct?
  3. I can only imagine that both proxy and all servers will need to auto-renew?

Is this all making sense?! I’ve looked around for a tutorial on this kind of set up as I feel as if I can’t be the only one thinking of doing this, but as yet I’ve not found one (but would be more than willing to write one up given a little direction - it could be useful within this forum?)

My domain is: mrm.giize.com

I ran this command: N/A

It produced this output: N/A

My web server: nginx 1.10.3 (proxy) / Apache2.0.47 (servers)

The operating system: Ubuntu 16

My hosting provider: N/A

I can login to a root shell: yes

I’m using a control panel: no

The version of my client is: 0.31.0

yes

depends. usually no.

server {
  listen 443 ssl;
  location / {
    proxy_pass http://192.168.1.100; 
    # Note: internal IP, over plain http
    # only do this if your internal network is "secure"
  }
}

Any server that renews will renew, but you can deploy certs with ssh while centralizing issuance.

In my case, I need to ensure that the connections within the VMware network are also secure so that the servers mimic live (and public) servers, all of which have TLS certs on them, so I would imagine that this line

proxy_pass http://192.168.1.100;

needs to read

proxy_pass https://192.168.1.100;

and the server (.100) has to have the LE certs installed on it too, correct?

That way all clients (public or internal) will make a call to (for example) server1.mrm.giize.com, be routed to the proxy server, and then the proxy server redirects to the server in question.

You might want to use a dns server (split horizon) and use their actual fqdn, then. You can use Let’s Encrypt certificates or you can make your own CA with minica, only the reverse proxy needs to trust it.

Advantages of making your own CA include: your internal certificates will not expire every 90 days, only the LE certs on the reverse proxy need to be renewed.

Ok @9peppe, thanks for your input … I’ll see how I get on with everything. Certainly appreciate your assistance, thank you!

1 Like

The “tls-alpn-01” challenge only requires port 443. This howto explains how to set it up.

Not necessarily. ngx_stream_ssl_preread_module can be used to dispatch TLS connections without terminating them.

It’s not a typical Nginx configuration, though.

Other software can do it, too.

1 Like

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