Feature request: multiple domains per app

[Rid]

For OS apps we could investigate allowing multiple domains per app.

The main challenge will be TLS termination at the reverse proxy, we need to see how we can keep SNI when calling the upstream.

[Rid]

There are really two ways to make this happen:

---

1. Do a straight TCP/TLS pass-through (so the container itself handles TLS and SNI)

In this model, nginx never terminates the client's TLS on port 443. We just let the TCP handshake (including TLS ClientHello/SNI) go straight to the container. That way, the container's web server (Apache/Nginx/whatever inside the OS) sees the SNI exactly as the client sent it, chooses its own cert, and serves.

How to set it up

1. Enable nginx's stream {} block.
   Instead of http {} we define a stream { } section in the nginx.conf (or in an include). It looks roughly like this:

   stream {
       map $ssl_preread_server_name $upstream_name {
           host1.example.com   user1_app;
           host2.example.com   user2_app;
           default             fallback_app;
       }
   
       upstream user1_app {
           server 10.0.1.5:8443;   # container's TLS port
       }
       upstream user2_app {
           server 10.0.2.7:8443;
       }
       upstream fallback_app {
           server 10.0.0.1:8443;
       }
   
       server {
           listen 443   
             ssl_preread on;         # sniff SNI without terminating TLS
           proxy_pass      $upstream_name;
           proxy_protocol  off;      # we can turn on proxy_protocol if the container needs client IP
       }
   }

   • ssl_preread on; tells nginx to peek at the ClientHello (SNI only) but not terminate TLS.
   • map $ssl_preread_server_name lets us pick an upstream block based on the client's SNI.
   • proxy_pass $upstream_name; sends the raw TCP stream (including the full TLS handshake) to the chosen backend.

2. Run the container with its own TLS certificate.

   • Inside the user's container (e.g. Debian, Ubuntu etc), configure their web server on port 8443 (or whatever) and install exactly the same cert/key pair that the client is expecting for host1.example.com (or host2.example.com, etc.).
   • Because the TLS handshake is happening end to end, the container can serve multiple domains (or even choose certs dynamically) exactly as if the client connected directly.

3. Pros and cons

   • Pros:
     • True end-to-end TLS. The container sees the client's SNI natively.
     • No need to re-encrypt or re-generate certs at the proxy level.
   • Cons:
     • nginx can't inspect or modify HTTP traffic. Everything is opaque TLS.
     • Harder to layer on WAF rules, rate-limit at HTTP level, etc.

---

2. Terminate TLS at nginx, then re-encrypt to the container ("TLS re-encrypt") and explicitly forward the original SNI

If we want nginx to terminate TLS (for logging, filtering, WAF, Let's Encrypt automation, etc.), but still let the upstream service see the client's hostname, we can "re-encrypt" from nginx to container and tell nginx to use the same server_name on the upstream TLS handshake. In other words, nginx is acting as both an HTTPS server (for the client) and as an HTTPS client (for the container).

Steps to re-encrypt with SNI preservation

1. Make sure each container has a matching certificate installed.

   • We'll need the same cert/key inside the container that nginx originally used for that domain.
   • In practice, we can mount (or copy) /etc/letsencrypt/live/host1.example.com/fullchain.pem and the corresponding privkey.pem into the container.
   • Inside the user's OS, configure the container's webserver to listen on port 8443 (or 443 internally) and load those certs.

2. Configure nginx's "client-side" (upstream) TLS to use the original server_name.
   In the http {} context, for any vhost that we want to re-encrypt, do something like:

   server {
       listen 443 ssl;                              # nginx terminates here first
       server_name host1.example.com;
   
       ssl_certificate     /etc/nginx/ssl/host1.crt; # the public cert
       ssl_certificate_key /etc/nginx/ssl/host1.key; # private key
   
       # … any other SSL settings, HSTS, ciphers, etc.
   
       # Now proxy_pass with client-side TLS back to the container:
       location / {
           proxy_pass        https://container_upstream;
           proxy_http_version 1.1;         # if we're proxying HTTP/1.1
           proxy_set_header  Host $host;   # preserve original Host header
           # (below two lines make nginx send the same SNI to upstream)
           proxy_ssl_server_name on;
           proxy_ssl_name           $host;
   
           # (optional) if the container's cert is self-signed, we may need:
           # proxy_ssl_verify       off;
           # or if we're using a private CA:
           # proxy_ssl_trusted_certificate /etc/nginx/ssl/my_ca.pem;
       }
   }
   
   upstream container_upstream {
       server 10.0.1.5:8443;   # container's IP and TLS port
   }

   Key bits:

   • proxy_ssl_server_name on; tells nginx to send an SNI extension when it opens the TLS handshake to 10.0.1.5:8443.
   • proxy_ssl_name $host; makes nginx use exactly the client-facing $host as the SNI for the upstream. If the DNS setup routes host1.example.com → nginx → container, then $host is host1.example.com, so the container sees that same SNI.
   • If the container is serving a cert that matches host1.example.com, the handshake will complete, and the container's web server will present its own copy of the same certificate.

3. Re-use the certificates (and how to share them).

   • The simplest way is to mount the same files from the reverse proxy into the container (e.g. via a volume). For example:

     docker run -d \
       -v /etc/letsencrypt/live/host1.example.com/fullchain.pem:/etc/ssl/certs/app.crt:ro \
       -v /etc/letsencrypt/live/host1.example.com/privkey.pem:/etc/ssl/private/app.key:ro \
       user1/debian-appbox
     

   • Inside the container, configure Nginx (or whatever TLS server) to use /etc/ssl/certs/app.crt and /etc/ssl/private/app.key.
   • As long as nginx-proxy and the container use identical key+cert, the client never has to worry about two different certificates.

4. Pros and cons

   • Pros:
     • nginx can still inspect, filter, and log HTTP/HTTPS traffic at the edge.
     • The container still "sees" exactly what hostname the client requested.
   • Cons:
     • We're effectively doing two TLS handshakes (client to nginx, nginx to container), which adds CPU/latency.
     • We must securely share the cert/key files with each container (or have a mechanism inside the container to fetch them).

---

Which approach should we pick?

• Use TCP pass-through (stream) if

  • We want true end-to-end encryption and we're okay with nginx having zero visibility into HTTP.
  • We don't need to rewrite headers or do any HTTP-level logic at the proxy.
  • We're just mapping each domain directly to that container and it already has its TLS cert.

• Use TLS re-encrypt (http proxy + proxy_ssl_server_name on) if

  • We rely on nginx to do things like path rewrites, caching, WAF, header injection, etc.
  • We still want the container to know which hostname was requested so it can serve multi-domain content (or use virtual hosts).
  • We don't mind running two TLS handshakes, but we do want to do layer-7 routing at the edge.

---

Example snippet: re-encrypting HTTPS with SNI

Below is a minimal example of how the nginx.conf (or /etc/nginx/sites-enabled/appbox.conf) might look if we choose the "terminate & re-encrypt" path:

http {
    # (1) Define an upstream pointing at the container's TLS port
    upstream mycontainer {
        server 10.0.1.5:8443;  # container's private IP: TLS port
    }

    # (2) The server block that listens for public HTTPS
    server {
        listen 443 ssl;
        server_name host1.example.com host1-alias.com;  # allow multiple domains

        # These live on the reverse-proxy host
        ssl_certificate      /etc/letsencrypt/live/host1.example.com/fullchain.pem;
        ssl_certificate_key  /etc/letsencrypt/live/host1.example.com/privkey.pem;

        # (3) Optional: any TLS settings (protocols, ciphers, HSTS, etc.)

        location / {
            # pass traffic to the container over HTTPS
            proxy_pass           https://mycontainer; 
            proxy_http_version   1.1;
            proxy_set_header     Host $host;
            
            # THIS is the magic that pushes the same SNI downstream:
            proxy_ssl_server_name on;
            proxy_ssl_name         $host;

            # (if the container's cert is self-signed, disable verification or provide CA):
            proxy_ssl_verify      off;
            # or:
            # proxy_ssl_verify      on;
            # proxy_ssl_trusted_certificate /etc/nginx/ssl/ca.pem;
        }
    }
}

• When a user browses to https://host1.example.com, nginx terminates TLS, reads the $host, then does an outbound https://10.0.1.5:8443 handshake using server_name = host1.example.com.
• The container sees ClientHello, server_name = host1.example.com, picks its own /etc/ssl/certs/app.crt (which must be valid for that name), and completes the handshake.
• From the container's point of view, it's just as if the client had connected directly to it over port 443.

---

Final notes

• Wildcard or SAN certificates can simplify life if a user wants dozens of subdomains (e.g. *.example.com). In that case we wouldn't have to regenerate per hostname; we'd just reuse the same wildcard cert both on nginx and in the container.
• Whenever we "re-encrypt," be careful with certificate management: we need to keep the same key+cert up to date inside both layers. Automating that (e.g. with a shared volume or a cert-syncing sidecar) is usually worth it.