Nginx配置问题：HTTPS代理时证书域名与Host头不匹配

Absolutely, you can resolve this certificate mismatch issue with a couple of simple Nginx configuration adjustments. Here’s how to tackle it:

1. Adjust the Host Header Sent to Server 2 #

The root problem here is that Nginx defaults to using the proxy target address (server2.example.com) as the Host header when sending requests to Server 2. Since Server 2’s certificate is only valid for example.com, this mismatch triggers a TLS error.

To fix this, force Nginx to pass the original request’s Host header (which is example.com) to Server 2 instead. Add this line inside your location block:

proxy_set_header Host $host;

Here’s a complete example of the Server 1 Nginx config:

server {
    listen 443 ssl;
    server_name example.com;

    # Your existing TLS cert/key config for Server 1
    ssl_certificate /path/to/example.com.crt;
    ssl_certificate_key /path/to/example.com.key;

    location / {
        # Pass the original Host header to Server 2
        proxy_set_header Host $host;
        # Optional: Pass other necessary headers like X-Forwarded-For
        proxy_set_header X-Forwarded-For $remote_addr;

        proxy_pass https://server2.example.com;
    }
}

This works because Server 2 will now see the request as coming for example.com, which matches its certificate’s common name. Just make sure Server 2’s Nginx config has server_name example.com; so it recognizes and processes the request correctly.

2. Override the SNI Name for the Proxy Connection (Alternative) #

If for some reason you need to keep the Host header as server2.example.com but still want the TLS handshake to validate against example.com, you can override the SNI (Server Name Indication) that Nginx uses when connecting to Server 2.

Add these two lines to your location block:

proxy_ssl_name example.com;
proxy_ssl_server_name on;

This tells Nginx to send example.com as the SNI value during the TLS handshake with Server 2, even though the proxy target is server2.example.com. The certificate validation will then pass because the SNI matches the cert’s common name.

Important Notes: #

• If you enable TLS certificate verification (which you should for security), ensure Server 1 trusts the CA that issued Server 2’s certificate. You can configure this with proxy_ssl_verify on; and proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;.
• Both solutions work because Server 2 already has the same TLS cert/key as Server 1—you’re just aligning the request metadata to match what the certificate expects.

内容的提问来源于stack exchange，提问作者izrik