strongSwan: typ klucza, loader i zły backend

PEM to kontener, a nie typ klucza. Porównaj klucz publiczny certyfikatu z prywatnym, a następnie wczytaj go przez backend, który naprawdę go czyta.

Rozszerzenia plików nie identyfikują algorytmów kluczy, a koperta .pem może zawierać materiał RSA lub ECDSA. PEM opisuje, jak pakowane są bajty, podczas gdy RSA i ECDSA nazywają różne algorytmy, a plik PKCS12 to jeszcze trzecia rzecz. strongSwan wczytuje poświadczenia przez wtyczki i backend konfiguracji, więc certyfikat może pojawić się na liście, podczas gdy klucz prywatny nigdy nie stanie się użyteczny. Rozdziel te warstwy, zanim edytujesz jakikolwiek sekret.

Kodowanie, algorytm i pakowanie to trzy warstwy

Plik klucza ma kodowanie, algorytm i często kontener. PEM to znana koperta base64; DER to jej binarny odpowiednik; PKCS12 łączy certyfikat z jego kluczem i łańcuchem. Plik łańcucha certyfikatów to kolejny kontener i zwykle nie zawiera żadnego klucza prywatnego. Żadna z tych etykiet nie mówi, czy materiał w środku to RSA czy ECDSA.

Czytaj algorytm z samego obiektu. Nazwa marketingowa dostawcy lub rozszerzenie pliku nie są dowodem, bo ten sam wystawca może wydawać różne typy kluczy.

Porównaj klucze publiczne, zanim obwinisz loader

Certyfikat, który się wczytuje, dowodzi, że certyfikat został przeanalizowany, a nie że jego klucz prywatny istnieje lub jest użyteczny. Wyprowadź klucz publiczny z certyfikatu i z proponowanego klucza prywatnego, a następnie porównaj oba skróty. Jeśli którekolwiek wyodrębnienie się nie powiedzie, zatrzymaj się, bo skrót pustego wyniku niczego nie dowodzi. Zgodne skróty dowodzą, że para do siebie pasuje, i niczego więcej o tym, czy certyfikat nadaje się do zadania.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

Druga komenda dotyka prywatnego materiału na twoim komputerze, ale wypisuje tylko publiczną połowę. Zostaw to tak i nigdy nie wklejaj klucza prywatnego do zgłoszenia. Jeśli klucz jest zaszyfrowany, pozwól obsługiwanemu narzędziu zapytać o hasło, zamiast umieszczać je w wierszu poleceń, gdzie lista procesów może je ujawnić.

Starsze ipsec.secrets lub poświadczenia swanctl

strongSwan ma dwie powszechnie używane ścieżki poświadczeń. Stary stos starter czyta wpisy specyficzne dla typu z ipsec.secrets, a każdy wpis musi wskazywać właściwy typ materiału. Stos swanctl i vici wczytuje klucze z własnego katalogu poświadczeń przez własną konfigurację. Edytowanie pliku, którego działający backend nie czyta, niczego nie zmienia.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Ustal, który backend naprawdę działa, a następnie umieść klucz tam, gdzie ten backend patrzy. stary podręcznik strongSwan 5.9 definiuje wpisy sekretów specyficzne dla typu i nie jest to dokumentacja swanctl. Mieszanie obu daje demona, który ignoruje plik, który administrator uważa za wiarygodny. Przeładowanie, które nie zgłasza błędu, oznacza tylko, że konfiguracja została przeanalizowana.

Czytaj zdarzenie wczytywania i wynik uwierzytelniania

Po kontrolowanym przeładowaniu przeczytaj własne wyjście wczytywania demona dla konkretnego klucza. Certyfikat wymieniony w zrzucie stanu nie pokazuje, że klucz prywatny został do niego dopasowany.

Jeśli klient nadal zawodzi, trzymaj zdarzenie serwera i błąd klienta osobno. Walidacja łańcucha, dopasowanie tożsamości i zgodność metod to późniejsze pytania z własnymi dowodami. Zapisz wynik z dokładną ścieżką klucza i skrótem, który porównałeś, bo inaczej następna zmiana powtórzy to samo przeładowanie. Zastąpienie CA nie jest pierwszą reakcją na niezgodność loadera.

Powiązane artykuły