web-dev-qa-db-ja.com

nginx $ ssl_client_i_dnの形式が突然変更されたのはなぜですか？

私たちは、顧客の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

これを解決するのは簡単でしたが、理由はわかりません。だから私の質問は本当に：

  1. $ssl_client_s_dnの価値はどこから来るのですか？ nginxによって設定されていますか？クライアント？
  2. この値が持つことができる形式のドキュメント/仕様はありますか？名前はありますか？
nginxsslssl-certificate
13
Patrik Stenmark

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.

この種のことを避けたい場合は、不安定なメインラインリリースではなく、安定したリリースに固執する必要があります。どちらの方法でも、プロダクションを盲目的にアップグレードする前に、最初にテストする必要があります。

18
Michael Hampton