nginx proxy_pass与后端请求客户端证书

我们正在代理后端，我们不控制后端在https上连接时请求客户端证书。

当我们通过代理请求这些页面时，连接超时而后端没有响应，但是如果我们绕过代理，页面就可以正常工作。这是处理客户端证书的nginx问题，还是应该在其他地方看？

Nginxconfiguration：

server { listen 443 ssl; ssl on; ssl_certificate /etc/nginx/ssl/webserver.pem; ssl_certificate_key /etc/nginx/ssl/webserver.key; location / { proxy_pass https://www.backendsite.com; proxy_set_header X-Forwarded-For $http_x_forwarded_for; } }

我不确定你是否意识到这一点，但是你在做什么是在www.backendsite.com上的一个中间人攻击。

要理解为什么在您的scheme中无法正常工作，我们需要解释证书和密钥在TLS中的实际作用。所以我们走了

首先，我们需要明确一个关键。我们没有，而且出于效率的原因不能有一个安全的渠道，所以我们使用Diffie Hellman作为我们的密钥交换协议。以前我们可能已经build立了我们使用的参数。现代思想认为这是一个坏主意，让我们走了一些。这就是所谓的DHE（短暂的Diffie Hellman）。如果你感觉真的很喜欢，你可以通过EC（EC-DHE）做到这一点。

现在的问题是，你怎么知道我使用DH发给你的参数？为了证实这一点，我们需要一个数字签名algorithm，以便您可以获得一些关于我的公开信息，以validation使用我的私钥生成的签名只能由我进行。

服务器密钥材料规定，对于服务器端 – 一个私钥和一个公钥（包含在证书中，加上CA的签名表示，我们也相信这一点）。

通常情况下，客户端可以根据感觉为匿名连接生成一个公钥/私钥对。所以在通常情况下：

客户端有任何旧的密钥对。
她与您的代理人build立了工作联系。 stream量通过这个隧道被encryption/解密。
代理具有它自己的“任何旧的密钥对”，它与服务器build立连接。
服务器并不太在乎谁是客户，它将与任何人build立连接，所以它使用你的代理的公钥。
会议成立。

但是，现在客户端提供了一个特定的密钥对。这个密钥对用于保护协议的参数，所以会发生什么情况：

客户端具有特定的密钥对，请求TLS并发送其参数和公钥。
代理解密，可以重新包装这两种方式之一（我不知道这些会实际发生 – 取决于实施 – 我只是解释为什么这不能工作）：
- 它提供客户的公共证书而不是它自己的。没有私钥，它不能解密任何会话响应。
- 所以在一个不愉快的事情（这实际上并不是什么情况，只是一个例证），并生成自己的证书。然而，服务器不会与证书进行通信，除了那些在给定条件下的证书（例如由某个已知的证书签名），因此拒绝协商连接。

之所以不起作用，是因为nginx试图作为一个http代理，根据需要启动和重新应用https，并且在两端build立的可信证书TLS正在devise中阻止MITM。

工程师可以在后端受其控制的地方进行一些替代devise决策。我在这里结束了，因为我想代理一个unix套接字，通过一些证书信息向前。这可以使用这些注意事项来使用nginxvalidation证书，并在HTTP标头上进行观察（不要传递整个原始证书）。