Certyfikat liścia ważny, łańcuch wygasł: czytaj głębokość

Błąd wygaśnięcia może należeć do wystawcy, a nie do liścia. Przeczytaj głębokość weryfikacji i dane wejściowe zaufania, zanim odnowisz certyfikat, który wciąż wygląda na aktualny.

Sprawdzasz certyfikat serwera, widzisz miesiące na zegarze, a klient wciąż odrzuca połączenie z komunikatem o wygaśnięciu. Czytana data należy do liścia, a skarga może dotyczyć czegoś głębiej w ścieżce. Weryfikacja przechodzi łańcuch, a każdy certyfikat wybrany przez ten przebieg może zawieść we własnym oknie ważności. Przeczytaj, który zawiódł, zanim cokolwiek odnowisz.

Głębokość nazywa certyfikat, który zawiódł

W diagnostyce OpenSSL głębokość 0 to certyfikat docelowy, a głębokość 1 to wystawca, który go podpisał; wyższe liczby prowadzą do kotwicy zaufania. Wygaśnięcie zgłoszone na głębokości 1 nie przeczy aktualnemu notAfter na liściu, więc ponowne sprawdzenie widocznego certyfikatu nigdy nie wyjaśni błędu.

Zapisz odcisk palca zawiedzionego certyfikatu wraz z jego subject, ponieważ różne certyfikaty mogą nosić tę samą nazwę CA. Podpisywanie krzyżowe tworzy dokładnie tę sytuację: ta sama instytucja pojawia się więcej niż raz, z różnymi datami ważności, a weryfikator wybrał tę, której się nie spodziewałeś. Znana etykieta nie jest identyfikatorem, a odcisk palca jest tym, co odróżnia dwa obiekty o tej samej nazwie.

Uważaj też na produkty z więcej niż jedną rolą certyfikatu. W OpenVPN Access Server certyfikaty chroniące interfejsy web są oddzielone od tych używanych do połączeń VPN, więc przeglądarka otwierająca stronę administracyjną niczego nie dowodzi o ścieżce tunelu.

Dane zaufania to nie to samo co kandydaci łańcucha

Podaj weryfikatorowi oba wejścia osobno i jawnie. Plik zaufania zawiera kotwice, które akceptujesz; niezaufany pakiet zawiera certyfikaty pośrednie oferowane do zbudowania ścieżki. Mieszanie ich to sposób, w jaki ludzie przypadkiem awansują certyfikat pośredni na korzeń, a potem dziwią się, dlaczego ten sam błąd podąża za nimi między maszynami.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Wyłączenie domyślnej ścieżki i magazynu przez -no-CApath -no-CAstore utrzymuje test uczciwym: wynik zależy wtedy od plików, które wskazałeś, a nie od tego, czemu stacja robocza przypadkiem ufa. Dokumentacja weryfikacji OpenSSL opisuje te opcje i diagnostykę, którą generują.

-show_chain wypisuje zbudowany łańcuch, gdy weryfikacja się powiedzie, co jest przydatne do potwierdzenia, że ścieżka jest tą zamierzoną. Gdy zawiedzie, zachowaj zgłoszoną głębokość i subject; te dwa pola mówią kolejnemu czytelnikowi, który certyfikat sprawdzić.

Czego to nie robi: nie odtwarza polityki każdego klienta. Pin, ograniczenie przeznaczenia lub kontrola tożsamości specyficzna dla klienta żyje w kliencie, nie w tym poleceniu. To są ustawienia do sprawdzenia, gdy weryfikacja na serwerze przechodzi, a połączenie nadal zawodzi. Trzymaj obie diagnozy osobno, inaczej odnowisz zdrowy certyfikat, goniąc błąd pinningu.

Co dowodzi sprawdzenie, a co pomija

To jest sprawdzenie ścieżki i przeznaczenia wobec pliku zaufania, który dostarczyłeś. Dla sprawdzenia nazwy HTTPS dodaj oczekiwaną nazwę hosta przez odpowiednią opcję; dla połączenia VPN zachowaj skonfigurowane kontrole tożsamości klienta i używaj materiału zaufania, który ten klient rzeczywiście czyta.

To, co wysyła serwer, to zestaw kandydatów, a nie ścieżka, którą twój klient ostatecznie zbuduje. Zaufanie lokalne i reguły budowania biblioteki kształtują wynik, dlatego ta sama odpowiedź może się zweryfikować na jednej maszynie i zawieść na innej. Porównaj utrzymywany magazyn zaufania i implementację TLS zawodzącego klienta z tymi działającego klienta, zanim założysz identyczną ocenę. Różnica tam wyjaśnia wiele raportów „zawodzi tylko ten laptop”.

Aby zobaczyć okno każdego certyfikatu zamiast po kolei, wypisz je jako zbiór:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

To drugie polecenie wymienia subjecty i wystawców bez ręcznego dekodowania każdego pliku, tak zauważasz certyfikat pośredni, którego data minęła, podczas gdy liść wciąż wygląda dobrze.

Napraw ścieżkę bez osłabiania weryfikacji

Gdy dostarczany jest wygasły certyfikat pośredni lub przestarzały certyfikat podpisany krzyżowo, pobierz aktualnie obsługiwany łańcuch wystawcy i wdróż go przez udokumentowany przepływ pracy z certyfikatami usługi. Gdy klientowi brakuje zamierzonej utrzymywanej kotwicy, zaktualizuj jego zarządzaną konfigurację zaufania lub oprogramowanie klienta. Oprzyj się pokusie oznaczenia każdego certyfikatu w pakiecie jako korzenia tylko po to, by uciszyć komunikat.

Obsługa korzenia zasługuje na uwagę, bo podsumowania często ją wyolbrzymiają. RFC 5280 traktuje kotwicę jako dane wejściowe poza przyszłą ścieżką, podczas gdy OpenSSL dokumentuje kontrole ważności obejmujące jego certyfikat CA korzenia. Oba stwierdzenia są prawdziwe dla ich własnych systemów; uogólnianie zachowania wygaśnięcia korzenia jednej biblioteki na każdego klienta daje pewne siebie błędne odpowiedzi.

Po zmianie wymuś nowe uwierzytelnienie na dotkniętym kliencie i potwierdź, że konkretny komunikat o wygaśnięciu zniknął. Odnów liść tylko wtedy, gdy sam liść jest nieodpowiedni. Wyłączenie kontroli czasu lub przywrócenie historycznego certyfikatu krzyżowego nie tworzy ważnej bieżącej ścieżki; tylko opóźnia następną awarię.

Powiązane artykuły