Dlaczego format nginx $ ssl_client_i_dn nagle się zmienił?

Używamy certyfikatów po stronie klienta do uwierzytelnienia jednego z naszych klientów.

Nasza konfiguracja jest następująca: mamy nginx przed aplikacją Django. W naszej nginx config mamy wymagane parametry, aby uzyskać rzeczywistą weryfikację klient-side-certyfikat do pracy ( ssl_client_certificate, ssl_verify_clientetc) i

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;

co oznacza, że ​​otrzymujemy wartości tych zmiennych do naszej aplikacji Django. Następnie aplikacja Django używa tych informacji do zidentyfikowania, który użytkownik się łączy i autoryzacji.

Z powodzeniem korzystamy z tego od kilku miesięcy, kiedy nagle zaczęliśmy otrzymywać raporty o tym, że ludzie nie mogą się zalogować za pomocą certyfikatów. Okazało się, że zmienił się format $ssl_client_s_dni $ssl_client_i_dnwartości z formatu oddzielonego ukośnikiem:

 /C=SE/O=Some organziation/CN=Some CA

do formatu rozdzielanego przecinkami:

CN=Some CA,O=Some organization,C=SE

Rozwiązanie tego było łatwe, ale nie rozumiem dlaczego. Więc moje pytania są naprawdę:

1. Skąd pochodzi wartość $ssl_client_s_dn? Czy jest ustawiony przez nginx? Klient?
2. Czy istnieje dokumentacja / specyfikacja formatu, który może mieć ta wartość i czy ma ona nazwę?

Zmieniły się, ponieważ nginx zmienił je w wersji 1.11.6. Jak pokazano w dzienniku zmian:

    *) 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.

Jeśli chcesz tego uniknąć, powinieneś trzymać się stabilnych wersji, a nie niestabilnych głównych wersji. Tak czy inaczej, powinieneś najpierw przetestować przed ślepą aktualizacją produkcji.