Błąd certyfikatu WWW w Access Server: pusty pakiet CA

Pusta wartość ca_bundle lub uszkodzony PEM zatrzymuje interfejs administracyjny. Sprawdź certyfikat, klucz i łańcuch jako jeden zestaw przed restartem i nie ruszaj PKI sieci VPN.

Strona logowania, która się nie ładuje, choć DNS rozwiązuje się poprawnie, zwykle nie jest problemem DNS. Jeśli dziennik usługi wspomina o pustej ścieżce pakietu certyfikatów albo o błędzie parsowania PEM certyfikatu WWW i klucza prywatnego, odbiornik HTTPS nie ma użytecznego materiału i rozwiązywanie nazw nie pomoże. Naprawa tkwi w trzech kluczach konfiguracji i nie wymaga ponownego wydania ani jednego certyfikatu klienta VPN.

Na co naprawdę wskazują trzy klucze

Własny zestaw certyfikatów WWW opisują cs.cert, cs.priv_key i cs.ca_bundle. Każdy przechowuje ścieżkę do pliku, a usługa WWW wykorzystuje wszystkie trzy razem. Certyfikat z niewłaściwym kluczem albo plik łańcucha, który w rzeczywistości jest certyfikatem liścia, zawodzi tak samo jak pusta wartość.

Te klucze należą do interfejsu WWW Admin i Client. Są oddzielone od PKI, która wydaje certyfikaty klientom VPN, więc wymiana nie wymaga dotykania profili, klucza serwera ani urzędu certyfikacji. Odbudowa całego PKI to najdroższy błąd w tym miejscu.

Jedno rozróżnienie oszczędza czas: jawnie pusta wartość własna to nie ten sam stan co brak nadpisania. Pierwsza daje parserowi pustą ścieżkę, i to mówi linia dziennika. Druga zostawia Access Server na własnym materiale.

Dlaczego istniejący plik nadal się nie parsuje

Parser czyta bloki z etykietami wewnątrz pliku, a nie nazwę pliku. .crt zawierający klucz prywatny, łańcuch zapisany jako jeden blok albo plik z uciętą ostatnią linią są odrzucane. RFC 7468 definiuje te czytelne etykiety, bo tylko one mówią, jaki typ obiektu następuje.

Oglądaj obiekty, nie rozszerzenia. Na hoście Linux openssl x509 -noout -subject -issuer -in server.pem i openssl pkey -noout -check -in key.pem odpowiadają na dwa ważne pytania, a porównanie modułu lub klucza publicznego dowodzi, że do siebie pasują. Trzymaj wynik klucza prywatnego z dala od zgłoszeń i logów czatu.

Pusta ścieżka zasługuje na taką samą nieufność jak uszkodzony plik, bo obie dają niejasne błędy w dalszych etapach. Jeśli dziennik mówi, że ścieżka pakietu jest pusta, odczytaj zapisaną wartość, zanim zaczniesz debugować plik.

Celowo wróć do wariantu zapasowego

CLI Access Server ma kontrolę walidacji, która przyjmuje trzy ścieżki jako argumenty i informuje, czy zestaw jest użyteczny. Ścieżki poniżej są przykładowe; zastąp je chronionymi lokalizacjami na hoście.

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Przeczytaj wynik, zanim dotkniesz działającej usługi, a dopiero potem zaimportuj wartości i zastosuj je udokumentowaną operacją dla zainstalowanej wersji. oficjalny samouczek CLI obejmuje walidację, import i krok zastosowania, a jego wersja liczy się bardziej niż jakiekolwiek podsumowanie.

Sprawdź nazwę, którą użytkownicy naprawdę wpisują

Gdy własny materiał jest zepsuty, a prawidłowy wbudowany wariant zapasowy nadal istnieje, udokumentowane odzyskiwanie polega na usunięciu trzech nadpisań i pozwoleniu Access Server na użycie tego wariantu. Najpierw zapewnij dostęp do konsoli i kopię bieżącej konfiguracji.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Wyczyszczenie całej bazy konfiguracji nie jest naprawą certyfikatu. Celuj w te trzy klucze, zastosuj i potwierdź, że interfejs WWW odpowiada. Pliki samopodpisane w katalogu web-ssl są zasobem zapasowym, a nie obszarem roboczym.

Spodziewaj się, że przeglądarka pokaże inny certyfikat po zadziałaniu wariantu zapasowego. To jest właściwy wynik; zweryfikuj go w zaufanym procesie administracyjnym.

Odzyskiwanie kończy się dopiero po udanym logowaniu

Odzyskiwanie nie kończy się, gdy pojawi się odbiornik TCP. Sprawdź nazwę DNS, tożsamość certyfikatu i łańcuch dla tej nazwy, następnie wczytaj oba interfejsy Admin i Client i dokończ logowanie. Kontrola portu nie dowodzi niczego z tego.

Access Server 3.1 i nowsze mogą obsługiwać różne certyfikaty WWW dla każdej nazwy hosta SNI. Jeśli tak skonfigurowano, klucze domyślne i wpisy dla konkretnej nazwy to osobne zestawy, a test przez adres IP łatwo pokaże inny certyfikat niż otrzymują użytkownicy. Napraw i sprawdź zestaw dla nazwy, która zawiodła, i powtórz test logowania przed zamknięciem incydentu.

Powiązane artykuły