0

I have the same scenario described in this question. I have a client connecting to an nginx reverse proxy with multiple backend services and need to set up certificates.

                             client
                               |
                             nginx
                       https://example1.com
                       https://example2.com 
                       https://example3.com
                             x.x.x.x
                               |
               -----------------------------------------
               |                |                      |
https://example1.com    https://example2.com    https://example3.com
   a.b.c.d:1234             e.f.g.h:5678            i.j.k.l:9012

What isn't clear to me from the answers there though is what the DNS names and IPs listed in each cert should be.

My understanding:

  • A reverse proxy isn't going to terminate the TLS connection so at no point will a client see the proxy's certificate
    • Edit: I realized that the reverse proxy could terminate the TLS connection, however in my case I need it to pass through
  • The proxy's certificates should list the hostname/IP address which the backend services example 1, 2, and 3 will see. Only the backend services will see those certificates

If the above two things are true what are the DNS names and IPs that should be listed in the certificates for the backend services? The client would need to see the proxy's hostname/IP in the certificates right? But the proxy should see their real IPs?

This is where I am confused.

Grant Curell
  • 1,043
  • 6
  • 19

1 Answers1

0

One of ways out is to terminate HTTPS traffic on Nginx and then passthrough to example1, example2 and example3. In that case client validates certificate it gets from the Nginx, so when you do connection to https://example1.com, then it will check if the CN=example1.com matches as well as it's simply valid and signed by a trusted CA. The client will see how this checking is being made between Nginx and the service to which Nginx passes to.

The problem is that this example contains the same exact listen address to which the client is supposed to connect to and the address to which the traffic should be proxied. This should be different, so for instance when connecting to https://example1.com, this traffic should be forwarded to https://example1-something.com (in order to avoid a loop).

Nginx can validate certificate to the proxied service, here is another question from serverfault about it. You can also ignore certificates but it's completely up to you how do you want to deal with it. From client's perspective what matters is that the it connect to a server with a valid, trusted certificate and this is outside of the given scope.

I haven't done this approach myself ever but technically you could try making a TCP proxy instead of HTTP proxy and then you would have to terminate certificates on the proxied machines, but I think this idea would be kinda boilerplate stuff and the first approach is easier to make.

Radosław Serba
  • 173
  • 1
  • 11