【问题标题】:Nginx Proxy pass certificate autentificate to MS IISNginx 代理通过证书 autentificate 到 MS IIS
【发布时间】:2016-01-24 20:03:34
【问题描述】:

Nginx 1.9.5 (linux Centos7)--> MS IIS 8.5 所以我尝试使用 nginx 作为 IIS 的客户端反向代理,在 IIS 级别需要客户端证书身份验证。 nginx:443->>IIS:443+客户端证书认证。

示例位置代理通行证 这里还有我尝试的注释命令。

location ^~ /test/ {
#proxy_buffering off;
#proxy_http_version 1.0;
#proxy_request_buffering off;
#proxy_set_header Connection "Keep-Alive";
#proxy_set_header X-SSL-CERT $ssl_client_cert;
# proxy_ssl_name domain.lv;
#proxy_ssl_trusted_certificate /etc/nginx/ssl/root/CA.pem;
#proxy_ssl_verify_depth 2;

proxy_set_header HOST domain.com;
proxy_ssl_certificate /etc/nginx/ssl/test.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/test_key.pem;
proxy_ssl_verify off;
proxy_pass https://10.2.4.101/;

 }

在 IIS 上很简单。

  1. 创建新网站。
  2. 在受信任的根目录中导入 CA 证书。
  3. 需要设置 ssl 证书。

测试我得到了什么:

  1. 需要通过浏览器直接访问 IIS 客户端证书——有效。
  2. Nginx 到其他 nginx 客户端证书需要--工作。
  3. Nginx 到 IIS 客户端证书忽略--工作
  4. 需要或接受 Nginx 到 IIS 客户端证书 - 不起作用

错误: Nginx 端: *4622 从上游读取响应头时上游超时(110:连接超时) IIS 端: 500 0 64 119971

所以我希望有人能知道为什么?

编辑 1. 也尝试从不同的服务器使用 nginx 1.8 没有任何帮助..

proxy_ssl_verify off;
proxy_ssl_certificate /etc/nginx/ssl/test/test.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/test/test_key.pem;
proxy_pass https://domain.com;

2.尝试与 apache 2.4 相同

SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLProxyMachineCertificateFile /etc/httpd/ssl/test.pem
ProxyPass "/test" "https://domain.com"

也许在 nginx 中进行 ssl 重新协商???

【问题讨论】:

    标签: authentication iis ssl nginx reverse-proxy


    【解决方案1】:

    您对 TLS 重新协商的预感是正确的。 Nginx 自 0.8.23 版起不允许 TLS 重新协商(请参阅http://nginx.org/en/CHANGES)。但是,默认情况下,IIS 在请求客户端证书时将使用 TLS 重新协商。 (我一直找不到原因 - 如果有人能启发我,我将不胜感激!)

    您可以使用诸如 wireshark 之类的数据包嗅探器来查看实际情况:

    1. IIS 和 Nginx 首先仅使用服务器证书执行 TLS 握手。
    2. Nginx 请求资源。
    3. 资源需要客户端身份验证,因此 IIS 向 Nginx 发送“Hello Request”消息以启动 TLS 重新协商。
    4. Nginx 不响应 Hello 请求,因为 TLS 重新协商已被禁用。
    5. IIS 然后关闭连接,因为它没有得到响应。 (参见https://technet.microsoft.com/en-us/library/cc783349(v=ws.10).aspx重新协商部分)

    要解决此问题,您必须强制 IIS 在初始 TLS 握手时请求客户端证书。您可以使用 powershell 中的 netsh 实用程序或命令行来执行此操作:

    1. 使用管理员权限打开一个 powershell 提示符。
    2. 输入netsh
    3. 输入http
    4. 输入show sslcert。您应该会在您的机器上看到所有当前 SSL 绑定的列表:

    1. 记下要为其启用客户端证书协商的证书的 IP:port 和证书哈希。我们现在将删除此绑定并重新添加它,并将协商客户端证书属性设置为启用。在本例中,IP:port 为 0.0.0.0:44300,证书哈希为 71472159d7233d56bc90cea6d0c26f7a29db1112。
    2. 输入delete sslcert ipport=[IP:port from above]
    3. 输入add sslcert ipport=[IP:port from above] certhash=[certificate hash from above] appid={[any random GUID (can be the same one from the show sslcert output)]} certstorename=MY verifyclientcertrevocation=enable verifyrevocationwithcachedclientcertonly=disable clientcertnegotiation=enable
    4. 您现在可以通过再次运行show sslcert 来确认这是否有效。您应该看到几乎相同的输出,但协商客户端证书设置为已启用:

    请注意,此方法仅适用于单个证书 - 如果您需要更改或更新证书,则必须再次运行这些步骤。当然,您应该将它们封装在批处理脚本或 MSI 安装程序自定义操作中,以便于部署和维护。

    【讨论】:

    • 非常感谢。它工作。这就是我想要的工作。我已经在 iis 和 nginx 之间安装了 apache 以进行临时解决。如果有人需要此服务器名称指示,请更改 Dave 文本的某些行 delete sslcert hostnameport=domain.com:443 add sslcert hostnameport=domain.com:443。
    • IIS 在重新协商后请求证书,因为管理员可以使客户端证书成为服务器上资源子集的要求,而使所有其他资源不受保护。因此,只有在资源名称已知时才请求证书是有意义的。
    猜你喜欢
    • 2017-06-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-01-07
    • 2013-07-25
    • 2016-07-12
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多