Twój klient VPN informuje, że nie udało się zweryfikować certyfikatu, i okno dialogowe na tym się kończy. Plik jest, serwer działa, a ten sam profil działał w zeszłym miesiącu na innym laptopie. Pod tym jednoliniowym ostrzeżeniem klient przepuścił certyfikat peera przez cztery bramy: urząd certyfikacji, który skonfigurowałeś, poręcza za ścieżkę podpisu, ta ścieżka dociera do urzędu, nazwa peera jest tą, o którą prosiłeś, a certyfikat jest teraz użyteczny do tego celu. Znajdź bramę, która się zamknęła, a naprawa to zwykle jeden plik; pomiń ten krok, a przez całe popołudnie będziesz ponownie importować paczki.

Przeczytaj okno dialogowe, zanim edytujesz profil

Komunikaty błędów certyfikatów formułuje biblioteka pod spodem, a nie zainstalowany produkt VPN, więc dokładny ciąg jest twoim pierwszym dowodem. „Nie można pobrać certyfikatu lokalnego wystawcy” wskazuje na ścieżkę lub na kotwicę zaufania. „Certyfikat wygasł lub nie jest jeszcze ważny” wskazuje na czas. „Nieobsługiwany cel certyfikatu” wskazuje na rozszerzone użycie klucza. Niezgodność nazwy mówi, jakiej nazwy oczekiwano. Żadnego z czterech nie naprawia ponowna instalacja klienta.

Podnieś poziom logowania, zanim cokolwiek zmienisz. OpenVPN zgłasza błąd weryfikacji wokół uścisku dłoni, gdy uruchomisz go z --verb 4, a strongSwan zapisuje swoje decyzje o tożsamości i łańcuchu w logu charon. Następnie potwierdź, który certyfikat badasz, bo ludzie rutynowo testują plik na dysku, podczas gdy profil osadza starszą kopię. Gdy profil osadza bloki PEM, testowany jest certyfikat osadzony.

Urząd certyfikacji podpisuje tożsamości, a nie uprawnienia

Urząd trzyma nazwę i klucz podpisujący. Wydaje certyfikaty, które wiążą klucz publiczny z tą nazwą według własnej polityki, z dołączonym okresem ważności i ograniczeniami użycia. Twój klient potrzebuje tylko certyfikatu urzędu, aby rozpoznać wystawcę; nigdy nie potrzebuje klucza podpisującego, a wysłanie tego klucza klientom dałoby im możliwość tworzenia dowolnej tożsamości, której ufa wdrożenie.

Zaufanie do urzędu czyni kandydatem każdy podpisany przez nie certyfikat, a nie właściwego peera. Certyfikat serwera WWW z tej samej wewnętrznej CA też jest kandydatem. Dlatego istnieją bramy nazwy i przeznaczenia i dlatego przejęty klucz CA waży więcej niż jakikolwiek pojedynczy serwer: sięga do każdej tożsamości, jaką urząd kiedykolwiek wydał. Wydawaj certyfikaty klientów na każde urządzenie, aby zgubiony laptop był jednym unieważnieniem, a nie wymianą kluczy dla całego wdrożenia.

Odtwórz ścieżkę, którą klient próbuje zbudować

Ścieżka biegnie od certyfikatu peera, przez zero lub więcej certyfikatów pośrednich, do korzenia w twoim magazynie zaufania. Brakujący certyfikat pośredni to najczęstsza awaria łańcucha, a z perspektywy klienta wygląda identycznie jak niezaufany korzeń. Najpierw przeczytaj liść, potem pozwól OpenSSL zbudować ścieżkę z materiału, który zamierzasz wysłać.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Status wyjścia zero oznacza, że ścieżka została zbudowana z tych plików; błąd nazywa certyfikat, do którego nie udało się dotrzeć. Jeśli openssl verify się powiedzie, a klient nadal odmawia, różnica tkwi w tym, co serwer faktycznie wysyła, albo w tym, który plik zaufania ładuje profil. W OpenVPN certyfikaty pośrednie mogą jechać z plikiem certyfikatu serwera albo być dostarczane osobno z --extra-certs, a paczka z dwoma korzeniami zapisanymi pod tą samą nazwą podmiotu wyśle jednego z twoich klientów w złą gałąź.

Nazwa i przeznaczenie to osobne bramy

Budowanie łańcucha nigdy nie pyta, czy nazwa jest twoja. OpenVPN sprawdza ją tylko wtedy, gdy profil ustawia --verify-x509-name, a stary zwyczaj dopasowywania samej nazwy zwykłej łamie się na certyfikatach, których tożsamości żyją w subjectAltName. Wdrożenia IKEv2 dopasowują skonfigurowaną tożsamość do wpisów SAN lub do nazwy wyróżniającej, zależnie od klienta, a wartość wildcard lub %any po cichu wyłącza porównanie, które, jak myślałeś, masz.

Następnie czas i przeznaczenie. Laptop, którego zegar spieszy się o kilka godzin, odrzuca certyfikat jeszcze nieważny, a wygasły certyfikat pośredni psuje ścieżkę, podczas gdy liść jest ważny. Awarie przeznaczenia pochodzą z certyfikatu bez serverAuth w rozszerzonym użyciu klucza lub z keyUsage, który nie pozwala na podpis uścisku dłoni, co OpenSSL zgłasza jako nieobsługiwany cel certyfikatu. Wydaj ponownie z właściwego szablonu; nic w tym komunikacie nie jest powodem wyłączania weryfikacji.

Unieważnianie działa tylko wtedy, gdy ktoś je skonfigurował

CRL ani odpowiedź OCSP nie są sprawdzane automatycznie. Na serwerze OpenVPN certyfikaty klientów są porównywane z listą tylko wtedy, gdy --crl-verify wskazuje na listę. Sprawdzanie certyfikatu serwera po stronie klienta zależy od implementacji i często go nie ma. strongSwan potrzebuje swojej wtyczki unieważniania i polityki, zanim zajrzy do CRL dla peera.

To wyjaśnia zgłoszenie, które w końcu do ciebie trafi: unieważniony certyfikat klienta nadal się łączy, a wszyscy dochodzą do wniosku, że unieważnianie jest zepsute. Nic nie sprawdzało. Opublikuj i odśwież CRL albo trzymaj certyfikaty klientów tak krótkotrwałe, by nieaktualne unieważnienie liczyło się krótko, i przećwicz ścieżkę unieważniania na certyfikacie laboratoryjnym, zanim będzie potrzebna podczas incydentu.

Kolejność naprawy, która zostawia weryfikację włączoną

Posortuj według objawu, zanim dotkniesz plików, bo każdy wiersz tabeli wysyła cię do innego obiektu.

Client saysMost likely gateFirst check
unable to get local issuer certificatetrust anchor or missing intermediateyour own openssl verify against the files the profile loads
expired or not yet validvalidity windowleaf and intermediate dates against the device clock
unsupported certificate purposeextended key usageserverAuth present, keyUsage allows the handshake
name mismatchpeer identitysubjectAltName entries versus the profile name

Przejdź listę za jednym razem: potwierdź plik, który ładuje profil, sam zbuduj ścieżkę, sprawdź, czy serwer wysyła certyfikat pośredni, porównaj zegar, odczytaj SAN, odczytaj EKU, a potem połącz się ponownie i patrz, jak ta sama linia logu znika. Jeśli urządzeniu nie można w ogóle dać CA, pinning jest uczciwą alternatywą, bo OpenVPN 2.6 akceptuje --peer-fingerprint i zawęża zaufanie do jednego klucza zamiast usuwać sprawdzanie. RFC 5280 jest odniesieniem dla znaczenia każdego z tych pól.

Powiązane artykuły