Home / server / Questions / 1166231
Accepted
OrkoPaede
Asked: 2024-10-07 04:37:59 +0800 CST

Reverse Proxy infront of Reverse Proxy (domain based routing)

  • 772

Here comes a probably strange question that is probably also wrongly asked.

I have the following network structure/plan...:

enter image description here

The idea is that someone who is responsible/authorized for network 1 and domain1.com has their own Rev. Proxy that they manage and take care of SSL certificates. The same applies to network 2.

The question is, is this even possible? Unfortunately, I'm not very familiar with SSL and proxies. I suspect that the Rev. Proxy that holds the SSL certificates must form the frontend.? If that's the case, it probably wouldn't work anyway. Then the question is whether there is another way? A kind of NAT based on http/https? Sounds a bit off... But I think the idea is clear.

If it were basically possible, then the question would be whether the order HaProxy->Nginx is the right one? And whether anyone can give me a tip or link on how to configure the frontend proxy correctly.

Thank you very much for your answers.

Update: For those who have something similar in mind, the haproxy config:

# Automaticaly generated, dont edit manually.
# Generated on: 2024-10-07 20:55
global
    maxconn         1000
    stats socket /tmp/haproxy.socket level admin  expose-fd listeners
    uid         80
    gid         80
    nbthread            1
    hard-stop-after     15m
    chroot              /tmp/haproxy_chroot
    daemon
    tune.ssl.default-dh-param   2048
    server-state-file /tmp/haproxy_server_state

frontend Front
    bind            your_public_ip:80 name your_public_ip:80   
    bind            your_public_ip:443 name your_public_ip:443   
    mode            tcp
    log         global
    timeout client      30000
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    acl         app1    req_ssl_sni -m end domain1.de
    acl         app2    req_ssl_sni -m end domain2.de
    use_backend Domain1_ipvANY  if  app1 
    use_backend Domain2_ipvANY  if  app2 

backend Domain1_ipvANY
    mode            tcp
    id          100
    log         global
    timeout connect     30000
    timeout server      30000
    retries         3
    load-server-state-from-file global
    stick-table type binary len 32 size 30k expire 30m
    
    acl clienthello req_ssl_hello_type 1
    acl serverhello rep_ssl_hello_type 2
    
    tcp-request inspect-delay 5s
    tcp-request content accept if clienthello
    
    tcp-response content accept if serverhello
    
    stick on payload_lv(43,1) if clienthello
    
    stick store-response payload_lv(43,1) if serverhello
    server          ProxyMan 192.168.7.1:8443 id 102 check inter 1000

backend Domain2_ipvANY
    mode            tcp
    id          100
    log         global
    timeout connect     30000
    timeout server      30000
    retries         3
    load-server-state-from-file global
    stick-table type binary len 32 size 30k expire 30m
    
    acl clienthello req_ssl_hello_type 1
    acl serverhello rep_ssl_hello_type 2
    
    tcp-request inspect-delay 5s
    tcp-request content accept if clienthello
    
    tcp-response content accept if serverhello
    
    stick on payload_lv(43,1) if clienthello
    
    stick store-response payload_lv(43,1) if serverhello
    server          ProxyMan 192.168.8.1:8443 id 103 check inter 1000
nginx

1 Answers

  1. Best Answer

    It is possible to have certificates for the same domain at multiple stages, which is especially common if the transit between the various stages is over untrusted networks and thus should be protected.

    A typical example is a content delivery network (CDN) like cloudflare, which terminates the TLS on their site but then forwards the traffic to the customer system somewhere else on the internet which has its own certificate to protect the communication between cloudflare and the final server.

    Since each of the servers/proxies needs both a certificate and private key for this and the private keys should not be shared, this usually means that proxies and servers have different certificates. From the perspective of the public client only the initial proxy needs to have a certificate trusted by the client, i.e. typically a certificate from a public CA like Let's Encrypt. Each other stage needs only a certificate trusted by the previous stage, which might be issued by some internal non-public CA or might even be self-signed.

    Note that you could also use domain based routing in HA proxy without terminating the TLS, by routing based on the server name which is visible in the TLS handshake (as long as no ECH is setup). Since in this case HA proxy does not terminate the TLS it does not need certificates either.

    • 0