我们有一个 Jira 服务器，它使用个人证书进行身份验证，然后进行标准用户/密码身份验证。例如，此个人证书通常安装在 Windows 证书存储中。典型的情况是，当打开 Jira 网站时，系统会提示用户选择要使用的证书进行身份验证。通过身份验证后，系统会提示用户输入用户名和密码。
对我来说，问题出现在从我们的 Jenkins 实例连接到 Jira 服务器时。我用来连接 Jira 服务器的插件不支持个人证书身份验证方案。有人给了我一个想法，使用反向代理来对 Jira 服务器进行身份验证，该服务器配置了我用来连接 Jira 服务器的服务帐户的个人证书。
我已经使用 Apache 创建反向代理，但似乎无法获得正确的配置，以便 Apache 在连接到 Jira 服务器时将个人证书传递给它。
答案1
Apache 不能直接传递证书，因为身份验证不是通过发送证书来完成的：它是作为 TLS 握手的一部分，通过对服务器发送的“质询”进行数字签名来完成的，这可以证明你拥有该证书和其私钥（不发送私钥本身）。
通常此类协议是故意设计的防止握手不会被“中继”到另一台服务器——也就是说，如果您的整个 TLS 连接都与 Apache 连接，那么您也只是向 Apache 进行身份验证，而不会向其他人进行身份验证。这是一项安全功能，可确保恶意 Web 服务器无法存储您的证书和证明以供日后使用，并冒充您发出请求。
但听起来你收到的建议是仅对 Jenkins 使用反向代理，并为反向代理创建身份验证证书本身而不是让它中继身份验证。
（事实上，让它按原样中继身份验证是没有意义的，因为这样你就会回到最初的问题：詹金斯不支持发送证书，那么代理到底要中继什么？）
反向代理的目的是转变完全不同的身份验证机制：
Jenkins 使用简单的用户名和密码来向代理进行身份验证。（不是 Jira 用户名/密码，而是您在代理服务器本身中配置的专用用户名/密码，例如通过 Apache“AuthType Basic” - 以确保除 Jenkins 之外的任何人都不允许使用代理。）
代理使用它自己的个人证书来向 Jira 进行身份验证，并为其分配 Jenkins 所需的权限。