我们有一个 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 所需的权限。