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

顧客の認証にクライアント側の証明書を使用しています。

セットアップは次のとおりです。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_dnand $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. この値が持つことができる形式のドキュメント/仕様はありますか？名前はありますか？

それらは、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.

この種のことを避けたい場合は、不安定なメインラインリリースではなく、安定したリリースに固執する必要があります。いずれにしても、本番環境を盲目的にアップグレードする前に、最初にテストする必要があります。