Zanim go przekonwertujesz: klucz SSH a certyfikat OpenVPN

Import kończy się błędem certyfikatu, więc oczywisty krok wygląda jak konwersja. Ten odruch prowadzi ludzi ścieżką, na której zmienia się rozszerzenie pliku, a odmowa pozostaje dokładnie taka sama. Wiersz ssh-ed25519 w authorized_keys i certyfikat klienta OpenVPN to odrębne obiekty poświadczeń, z różnymi wystawcami, różnymi kodowaniami i różnymi ścieżkami unieważniania. Przejście tych kontroli po kolei powie ci w ciągu minuty, czy konwersja może w ogóle pomóc.

Który obiekt naprawdę masz?

Ludzie nazywają kluczem pięć rzeczy, a tylko jedna z nich jest tym, czego chce profil TLS. Klucz publiczny SSH to jedna linia tekstu z prefiksem typu i ładunkiem base64. Certyfikat OpenSSH to ten klucz plus podpis, principals i opcje, tworzone przez ssh-keygen działający jako własne małe CA. Certyfikat X.509 to zupełnie inna struktura: niesie podmiot, okno ważności, rozszerzenia i podpis urzędu certyfikacji. Klucz prywatny to tajna połowa, a wydany pakiet to zwykle certyfikat plus jego łańcuch plus klucz prywatny w jednym pliku.

Pierwszy test kosztuje jedno polecenie. Skieruj openssl na plik i poproś o analizę struktury certyfikatu:

openssl x509 -in client.crt -noout -subject -issuer

Jeśli to się nie uda z błędem unable-to-load lub PEM, plik nie jest certyfikatem X.509, jakkolwiek go nazwałeś. Zmiana nazwy nie przepisuje ASN.1 wewnątrz, a owijanie wiersza klucza publicznego w tekst nagłówka PEM też tego nie robi.

Czy profil w ogóle prosi o certyfikat?

Certyfikaty klienta to jedna z kilku metod uwierzytelniania, a wiele działających profili TLS nigdy o żaden nie prosi. Serwer może uwierzytelniać użytkowników przez wtyczkę, nazwę użytkownika i hasło albo backend tokenów, jednocześnie wymagając od klienta weryfikacji tożsamości serwera. Jeśli profil nie zawiera dyrektywy certyfikatu klienta, certyfikat nigdy nie zostanie zażądany, a żadna konwersja nie zmusi bramy, by o niego poprosiła.

Starsze konfiguracje z kluczem statycznym to trzeci przypadek. Powstały przed uzgadnianiem TLS i oczekują pliku wcześniej współdzielonego sekretu, dlatego wklejenie klucza publicznego w to pole też nie może zadziałać. Przeczytaj, czego profil naprawdę wymaga, zanim uznasz, że poświadczenie jest nieprawidłowe.

Co przekodowanie może, a czego nie może

Klucze prywatne mają legalne alternatywne kontenery. Ten sam klucz RSA lub EC można zapisać jako tradycyjny PEM, jako PKCS#8 lub wewnątrz pakietu PKCS#12, a narzędzia chętnie konwertują między nimi. Klucze publiczne mają podobną historię: ssh-keygen potrafi wypisać postać RFC 4716 klucza SSH, a OpenSSH rozumie także własny format certyfikatu. To wszystko jest reprezentacją, a reprezentacja nie jest zaufaniem.

Czego konwersja nie potrafi, to utworzyć podpisu urzędu certyfikacji, który nigdy nie widział twojego klucza. Certyfikat to twierdzenie wystawcy, że dany klucz publiczny należy do danego podmiotu w danym celu. Przekodowanie zachowuje bajty klucza i pozostawia twierdzenie nieobecne, więc brama nie ma czego zweryfikować wobec swojego magazynu zaufania.

To etap, na którym większość prób po cichu zawodzi: plik kończy się teraz na .crt, klient czyta go bez skargi, a uzgadnianie nadal się przerywa, bo druga strona nie potrafi zbudować łańcucha do zaufanego wystawcy.

Gdzie w obraz wchodzi urząd certyfikacji

Prawdziwa rejestracja zaczyna się od pary kluczy, którą kontrolujesz, oraz żądania podpisania certyfikatu niosącego podmiot oczekiwany przez operatora. Operator weryfikuje uprawnienie, podpisuje żądanie kluczem CA i zwraca wydany certyfikat wraz z dowolnym łańcuchem pośrednim, który klient musi przedstawić. Potem klient potrzebuje certyfikatu CA, który go podpisał, bo to on pozwala potwierdzić, że serwer, z którym rozmawia, należy do tego samego wdrożenia.

Ten ostatni plik łatwo zapomnieć i nie da się go zastąpić. Sam klucz podpisujący CA nigdy nie należy do konfiguracji klienta, a żadna lokalna konwersja nie wytwarza łańcucha, który powinieneś otrzymać.

Ile kosztuje cię ponowne użycie klucza SSH

Załóżmy, że konwersja rzeczywiście dała coś akceptowalnego. Ponowne użycie jednej pary kluczy do dostępu SSH i uwierzytelniania VPN nadal sprzęga dwie niezależne decyzje bezpieczeństwa. Usunięcie wpisu z authorized_keys zatrzymuje logowania SSH i nic nie robi certyfikatowi, który CA VPN już wydał dla tego samego klucza publicznego. Strona VPN jest unieważniana własnym mechanizmem, czyli listą unieważnionych certyfikatów lub rejestrem operatora.

Dlatego lista kontrolna kończy się warunkiem zatrzymania, a nie sztuczką. Jeśli openssl nie przeanalizuje pliku jako certyfikatu, przestań konwertować i opisz, co masz: klucz SSH, certyfikat SSH, certyfikat X.509, klucz prywatny lub pakiet. Jeśli profil nie prosi o certyfikat klienta, zatrzymaj się i zapytaj, jakiej metody uwierzytelniania oczekuje serwer. Dopiero gdy obie odpowiedzi wskazują X.509, rejestracja staje się następnym krokiem, a ta rozmowa idzie znacznie szybciej z właściwym rzeczownikiem w pierwszym zdaniu.