Pat*_*ark 13 ssl nginx ssl-certificate
我们正在使用客户端证书来验证我们的一位客户。
我们的设置是这样的:我们在 Django 应用程序前面有 nginx。在我们的nginx的配置,我们拥有所需的参数,以获得实际的客户端证书验证工作(ssl_client_certificate
,ssl_verify_client
等)和
uwsgi_param X-Client-Verify $ssl_client_verify;
uwsgi_param X-Client-DN $ssl_client_s_dn;
uwsgi_param X-SSL-Issuer $ssl_client_i_dn;
Run Code Online (Sandbox Code Playgroud)
这意味着我们将这些变量的值输入到我们的 Django 应用程序中。Django 应用程序然后使用此信息来识别哪个用户正在连接并授权他们。
我们已经成功地使用了几个月没有任何问题,突然我们开始收到有关人们无法使用证书登录的报告。结果发现$ssl_client_s_dn
和$ssl_client_i_dn
值的格式发生了变化,从斜杠分隔的格式:
/C=SE/O=Some organziation/CN=Some CA
Run Code Online (Sandbox Code Playgroud)
以逗号分隔的格式:
CN=Some CA,O=Some organization,C=SE
Run Code Online (Sandbox Code Playgroud)
解决这个问题很容易,但我不明白为什么。所以我的问题是:
$ssl_client_s_dn
从何而来?是nginx设置的吗?客户端?Mic*_*ton 18
它们发生了变化,因为 nginx 在 1.11.6 版中更改了它们。如变更日志所示:
Run Code Online (Sandbox Code Playgroud)*) Change: format of the $ssl_client_s_dn and $ssl_client_i_dn variables has been changed to follow RFC 2253 (RFC 4514); values in the old format are available in the $ssl_client_s_dn_legacy and $ssl_client_i_dn_legacy variables.
如果你想避免这种事情,你应该坚持稳定版本,而不是不稳定的主线版本。无论哪种方式,您都应该在盲目升级生产之前先进行测试。
归档时间: |
|
查看次数: |
5155 次 |
最近记录: |