Certyfikat VPN jeszcze nie jest ważny: trzy przyczyny, jedna kolejność sprawdzania
Jeszcze nie jest ważny oznacza, że zegar urządzenia się spóźnia, okno naprawdę zaczyna się później albo certyfikat pośredni jeszcze się nie otworzył. Sprawdź je w tej kolejności.
Otwierasz klienta, wybierasz profil, którego używasz od miesięcy, i zatrzymuje się z "certificate is not yet valid". Nic w twoim logowaniu się nie zmieniło, a magazyn zaufania jest prawdopodobnie w porządku: certyfikat przedstawiony w uzgadnianiu ma okno ważności, które zaczyna się później niż chwila używana przez weryfikator. Trzy różne sytuacje dają dokładnie ten komunikat i wymagają różnych działań. Poniższa kolejność powie ci, którą masz, zanim dotkniesz zegara lub pliku certyfikatu.
Którą z trzech przyczyn widzisz
Pierwsza przyczyna jest lokalna: urządzenie wykonujące sprawdzenie ma zegar wcześniejszy niż data rozpoczęcia certyfikatu. Widać to na sprzęcie z martwą baterią CMOS, na maszynach wirtualnych przywróconych ze starego zrzutu, na urządzeniach wyłączonych wystarczająco długo, by straciły czas, oraz w sieciach, w których wychodzący NTP jest zablokowany i nikt tego nie zauważył. Certyfikat może być całkowicie ważny i mimo to zawieść w ten sposób.
Druga przyczyna należy do wystawcy, bo certyfikat naprawdę zaczyna się w przyszłości: wystawiony wcześnie, wygenerowany z jawnym czasem rozpoczęcia albo podpisany w ramach kroku aktywacji, który jeszcze się nie wykonał. Trzecia przyczyna marnuje najwięcej czasu, bo liść jest aktualny, a inny certyfikat w przedstawionym łańcuchu nie, więc błąd wskazuje materiał, którego nigdy nie zainstalowałeś.
Jedno pytanie je rozdziela. Czy awaria idzie za urządzeniem, czy za usługą? Dwie maszyny w tej samej sieci zachowujące się różnie wskazują na zegary. Gdy każdy klient zawodzi tak samo, wskazuje to na okno certyfikatu i łańcuch za nim.
Odczytaj okno z certyfikatu, który faktycznie został przedstawiony
Nie sprawdzaj pliku PEM pozostałego po wcześniejszym wdrożeniu; poproś usługę o łańcuch, który wysyła teraz. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts wypisuje każdy certyfikat w łańcuchu. Zapisz potrzebny blok i uruchom openssl x509 -noout -subject -issuer -dates; ostatni wypisuje notBefore i notAfter, a te dwie wartości decydują. W systemie Windows okno certyfikatu połączenia oraz certutil -dump na wyeksportowanym pliku pokazują te same pola.
Czytaj oba końce okna, nie tylko początek. Certyfikat, który otwiera się za dwie godziny, i ten, który zamyka się za dwie godziny, zawodzą z różnymi komunikatami i angażują różne zespoły. Zanotuj, który certyfikat nazywa błąd — liść, pośredni czy główny — bo to decyduje, czy po stronie klienta da się w ogóle coś naprawić.
Możesz też przetestować okno bez czekania na nie. Weryfikacja przyjmuje jawny czas: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem ocenia łańcuch według tego znacznika czasu. Uruchom go z bieżącym czasem, by odtworzyć awarię, a potem z czasem rozpoczęcia certyfikatu, by potwierdzić, że ten sam łańcuch przechodzi, gdy okno się otwiera. RFC 5280 definiuje pole ważności i zasadę, że certyfikatu nie wolno używać poza nim, i właśnie tę zasadę twój klient przed chwilą wyegzekwował.
Twój zegar czy ich
Porównaj zegar urządzenia z początkiem certyfikatu w UTC, ze źródła, któremu ufasz. date -u podaje chwilę, a timedatectl status na hoście systemd raportuje też, czy zegar jest zsynchronizowany. W systemie Windows w32tm /query /status pokazuje bieżące źródło i ostatnią udaną synchronizację. Strefa czasowa widoczna w zasobniku to wybór wyświetlania, a nie zły zegar; weryfikator porównuje chwile UTC.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
Jeśli zegar się spóźnia, zsynchronizuj ponownie i przetestuj ponownie, zanim zmienisz jakikolwiek materiał certyfikatu. Urządzenie odbiegające o minuty lub godziny odrzuca każdy niedawno wydany certyfikat, na jaki trafi, nie tylko jedną usługę, więc wyjaśnienie jedną usługą jest zwykle tym błędnym. Jeśli zegar jest poprawny i zsynchronizowany, przestań patrzeć na urządzenie: okno należy do wystawcy i żadne ustawienie lokalne nie powinno być zmieniane, by je przepuścić.
Ta tabela to cała decyzja. Przesunięcie zegara na to, czego oczekuje certyfikat, nie jest naprawą, a wyłączenie kontroli czasu też nie, bo oba ukrywają stan, który wywołał błąd.
Dlaczego łańcuch zawodzi, gdy liść wygląda dobrze
Odnowione liście i zamienne certyfikaty pośrednie są zwykle dostarczane razem i nie zawsze trafiają w tym samym momencie. Usługa może wysłać nowy liść podpisany przez pośredni, którego własne okno zaczyna się później, albo nadal serwować starszy pośredni pod świeżym liściem. Tak czy inaczej łańcuch zawodzi, podczas gdy daty samego liścia wyglądają rozsądnie.
Punkty końcowe z równoważeniem obciążenia zmieniają to z zepsutego w niespójne. Jeśli ponowna próba się udaje albo jedna sieć działa, a inna nie, zanotuj, który peer odpowiedział i który łańcuch wysłał, zanim zmienisz ustawienia. openssl s_client wypisuje połączony adres, więc kilka prób ujawnia, czy każdy węzeł serwuje ten sam łańcuch.
Ścieżki naprawy, które zachowują weryfikację
Problem zegara naprawia się na urządzeniu przy włączonej weryfikacji. Problem certyfikatu naprawia operator materiałem wydanym dla okna, które już obejmuje teraz. Żadne ustawienie klienta nie czyni jeszcze-nieważnego certyfikatu ważnym; flagi pomijające kontrole czasu istnieją po to, by potwierdzić diagnozę, a nie po to, by je wdrażać.
Gdy certyfikat jest przygotowany do planowanej aktywacji, postępuj zgodnie z planem przejścia. Zainstaluj go, gdy otworzy się jego okno, albo użyj procedury nakładania dokumentowanej przez dostawcę, zamiast instalować go wcześnie i uczyć użytkowników klikania ostrzeżeń. Ostrzeżenia, których ludzie uczą się ignorować, kosztują więcej niż krótkie opóźnienie.
Na koniec przetestuj ponownie tak, jak powstała awaria: nowa sesja, ten sam klient, zasób, którego naprawdę potrzebujesz. Biblioteki TLS mogą buforować zweryfikowany łańcuch przez cały czas życia połączenia, a wznowiona sesja niekoniecznie sprawdza go ponownie, więc stara sesja może dalej zawodzić po naprawie albo dalej działać po regresji. Plik, który otwiera się w przeglądarce, dowodzi tylko, że plik jest czytelny; ukończone uzgadnianie dowodzi, że łańcuch się weryfikuje.
Zanim zamkniesz zgłoszenie, potwierdź cztery rzeczy: czas UTC i stan synchronizacji zawodzącego urządzenia, notBefore i notAfter każdego certyfikatu w przedstawionym łańcuchu, ten sam łańcuch z drugiego klienta oraz nazwę, którą błąd nadaje certyfikatowi. Jeśli zegar jest poprawny, a okno się nie otworzyło, reszta należy do operatora, a właściwym krokiem po twojej stronie jest czekanie na okno zamiast osłabiania kontroli.