私たちは、顧客の1人を認証するためにクライアント側の証明書を使用しています。
私たちのセットアップはこれです: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;
つまり、これらの変数の値をDjangoアプリに取り込みます。Djangoアプリは、この情報を使用して、接続しているユーザーを特定し、それらを承認します。
証明書を使用してログインできない人に関するレポートを突然取得し始めたとき、問題なくこれを数か月間使用して成功しました。 $ssl_client_s_dn
と$ssl_client_i_dn
の値の形式が、スラッシュで区切られた形式から変更されていることがわかりました。
/C=SE/O=Some organziation/CN=Some CA
カンマ区切り形式に:
CN=Some CA,O=Some organization,C=SE
これを解決するのは簡単でしたが、理由はわかりません。だから私の質問は本当に:
$ssl_client_s_dn
の価値はどこから来るのですか? nginxによって設定されていますか?クライアント?Nginxがリリース1.11.6で変更したため、変更されました。変更ログに示されているように:
*) 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.
この種のことを避けたい場合は、不安定なメインラインリリースではなく、安定したリリースに固執する必要があります。どちらの方法でも、プロダクションを盲目的にアップグレードする前に、最初にテストする必要があります。