nieobsługiwany cel certyfikatu: dlaczego pośredni CA zawodzi

Cel certyfikatu serwera wygląda poprawnie, klucz się zgadza, daty są w porządku, a połączenie nadal kończy się błędem unsupported certificate purpose. Szczegół, który to rozwiązuje, zwykle znajduje się w tej samej linii co błąd: wartość głębokości i subject wskazujące certyfikat wyżej w łańcuchu. Uruchamiane są dwa różne testy i tylko jeden z nich dotyczy certyfikatu końcowego. Ich porównanie wyjaśnia, dlaczego wymiana certyfikatu serwera niczego nie zmienia.

Który certyfikat weryfikator faktycznie odrzucił

Łańcuch nie jest jednym obiektem powtórzonym trzy razy. Certyfikat końcowy zawiera nazwę i klucz serwera, certyfikaty pośrednie łączą go z korzeniem, a każdy ma własny okres ważności, ograniczenia i zastosowania. Gdy błąd podaje głębokość, liczba ta wskazuje pozycję w łańcuchu zbudowanym przez weryfikator, która może nie być pozycją, której oczekujesz, jeśli serwer wysyła nieoczekiwany łańcuch.

Czytaj pola certyfikatu na tej głębokości, a nie certyfikatu, który uznałeś za winny. Poproś o dwa rozszerzenia ograniczające wydawanie zamiast zrzucać każde pole, ponieważ odpowiedź prawie zawsze jest w jednym z nich. Wynik rozszerzeń można bezpiecznie udostępniać; kluczy prywatnych nigdy.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Jeśli wskazany certyfikat jest pośredni, a jego rozszerzone użycie klucza wspomina coś niezwiązanego z uwierzytelnianiem serwera TLS, reszta błędu wynika mechanicznie. Łańcucha nie można użyć do celu, o który poprosił OpenVPN.

Cel certyfikatu końcowego i polityka łańcucha to dwa testy

Test certyfikatu końcowego zadaje wąskie pytanie: czy ten certyfikat podmiotu końcowego zezwala na uwierzytelnianie serwera dla tej nazwy? Test łańcucha zadaje szersze: czy każdy certyfikat na ścieżce może służyć temu celowi? Urząd certyfikacji uprawniony do wydawania wyłącznie certyfikatów klienta przejdzie własne kontrole podpisu i mimo to nie przejdzie drugiego testu, ponieważ ścieżka, którą autoryzuje, nie obejmuje celu potrzebnego aplikacji. Oba testy zawodzą przy tych samych słowach i mają zupełnie różne naprawy.

Dlatego świeżo wydany certyfikat końcowy, poprawny w każdym widocznym polu, może zawieść natychmiast. Dlatego poprawka zwykle należy do profilu urzędu wydającego, a nie do konfiguracji VPN.

Brak EKU to nie restrykcyjne EKU

RFC 5280 czyni rozszerzenie rozszerzonego użycia klucza opcjonalnym i, gdy jest obecne, ograniczającym. Certyfikat CA bez tego rozszerzenia nie powiedział więc „nie” uwierzytelnianiu serwera, podczas gdy certyfikat wymieniający tylko niepowiązany cel powiedział coś bardzo konkretnego. Traktowanie tych dwóch stanów jako równoważnych daje błędną diagnozę i, co gorsza, błędną naprawę. Różnica wyjaśnia też, dlaczego dwa urzędy, które w konsoli wyglądają podobnie, zachowują się w łańcuchu zupełnie inaczej.

Zachowanie bibliotek też nie jest tu jednolite. dokumentacja OpenSSL dotycząca opcji weryfikacji opisuje własne podejście do kontroli celu w certyfikatach CA, a to podejście jest polityką implementacji, nie regułą, której każdy stos TLS przestrzega identycznie. Opisz, co robi twój weryfikator, a następnie potwierdź to na wersji, którą naprawdę uruchamiasz.

Odtwórz błąd offline, zanim wydasz ponownie

Weryfikacja offline usuwa aplikację z równania. Jeśli łańcuch zawodzi tak samo przy tym samym celu, problemem jest certyfikat i żadna konfiguracja serwera tego nie ukryje. Jeśli łańcuch przechodzi offline, a usługa nadal odmawia, aplikacja żąda innego celu lub używa innego łańcucha niż testowany.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain ma znaczenie, ponieważ drukuje ścieżkę zbudowaną przez narzędzie, a ta często nie jest kolejnością plików, którą podałeś. Ten wynik to najszybszy sposób, aby odkryć, że drugi certyfikat pośredni jest pobierany z magazynu zaufania, że serwer wysyła niechciany wariant podpisany krzyżowo lub że flaga celu skopiowana z poradnika należy do innej roli niż obsługiwana.

Napraw politykę wydawania, nie wywołanie weryfikacji

Trwałą naprawą jest certyfikat pośredni wydany zgodnie z polityką, która pozwala na cele, którym musi służyć, z zapisanym i przejrzanym ograniczeniem. Dodawanie każdego celu do każdego urzędu nie jest polityką; usuwa ograniczenie, które nadawało rozszerzeniu sens, i zwykle przeżywa incydent, który je wywołał. Krótka notatka w profilu opisująca, jakie role urząd może certyfikować, zapobiega powtórzeniu tej samej dyskusji przy kolejnym wydaniu.

Wyłączenie weryfikacji to druga kusząca skrótowa droga i zamienia problem certyfikatu w problem zaufania. Zachowaj kontrolę celu, popraw łańcuch i ponownie uruchom tę samą weryfikację offline, aby potwierdzić, że ścieżka służy teraz zamierzonej roli, zanim ponownie dotkniesz usługi.