Kopiowanie certyfikatu VPN nie kopiuje klucza

Przewodnik zaczyna się na liście certyfikatów klienta, gdzie wpis pokazuje nazwę, wystawcę i datę ważności i nic więcej. Wyeksportuj go, zaimportuj na drugim urządzeniu, a połączenie zostanie odrzucone, bo klient nie potrafi dowieść posiadania klucza prywatnego. Plik został skopiowany w całości; błąd polega na oczekiwaniu, że certyfikat niesie własny klucz. Przeczytaj okno eksportu, zanim wybierzesz format, a potem obejrzyj plik, który naprawdę otrzymałeś.

Dwa kliknięcia, dwa bardzo różne artefakty.

Czytaj okno eksportu, nie rozszerzenie pliku

Eksport certyfikatu DER lub PEM zawiera klucz publiczny i podpisane twierdzenia tożsamości, czyli to, czego serwer potrzebuje, by ci zaufać, i czego klient potrzebuje, by zweryfikować serwer. Pakiet PKCS#12 to kontener, który może przechowywać certyfikat, jego łańcuch i pasujący klucz prywatny, chroniony hasłem, choć można go utworzyć także bez klucza.

PEM to tylko kodowanie tekstowe, a nie obietnica co do zawartości. To samo rozszerzenie może opisywać jeden certyfikat albo plik z kilkoma oznaczonymi blokami, a decydują o tym opcje eksportu.

Więc użyteczne pytanie nigdy nie brzmi, jakie rozszerzenie dostałeś, ale jakie bloki zawiera plik. Pakiet wyeksportowany bez klucza nadal jest pakietem. Sprawdzaj zawartość, a nie popularność formatu.

Sprawdź, co naprawdę dostałeś

Szukaj etykiet, zanim cokolwiek zaimportujesz, a potem przeczytaj pola certyfikatu, by potwierdzić, jaką tożsamość trzymasz. Wykonaj kontrole na pliku, który naprawdę zostanie zaimportowany. Powtórz je po każdym ponownym eksporcie, bo opcje mogą się różnić.

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

Eksport zawierający tylko blok certyfikatu jest obiektem publicznym i nie może się uwierzytelnić. Blok klucza bez certyfikatu zostawia cię bez łańcucha, którego oczekuje serwer. Dane wyjściowe PKCS#12 informują też, czy klucz jest obecny, co rozstrzyga tę kwestię dla tego formatu. Podają również algorytm i rozmiar klucza, a gdy klucza nie ma, kończą się całkowitym niepowodzeniem.

Nigdy nie wklejaj pliku zawierającego klucz prywatny do wątku pomocy, systemu zgłoszeń ani czatu, nawet gdy wygląda jak certyfikat, który już udostępniałeś. Zrzuty ekranu panelu kluczy zasługują na tę samą ostrożność.

Klucz może mieszkać tam, skąd nie da się go skopiować

Na urządzeniach zarządzanych klucz prywatny może znajdować się w pęku kluczy systemu operacyjnego, w tokenie sprzętowym lub w bezpiecznym enklawie, a polityka oznacza go jako nieeksportowalny. Menedżer certyfikatów pokazuje wtedy obiekt publiczny, podczas gdy sekret zostaje na miejscu, i żadne polecenie eksportu nie wytworzy przenośnej kopii. Rejestracja przez zarządzanie urządzeniami mobilnymi często działa właśnie tak z założenia.

To jest mechanizm kontroli, a nie przeszkoda do obejścia. Odtworzenie klucza prywatnego z publicznego certyfikatu nie jest możliwe, a każde narzędzie, które to twierdzi, robi coś innego.

Zarejestruj nową tożsamość zamiast kopiować

Wspierana droga to zwykle zarejestrowanie odrębnej tożsamości dla nowego urządzenia i unieważnienie starej, gdy przechodzi na emeryturę, dzięki czemu każde urządzenie można wycofać niezależnie. Tam, gdzie eksport z kluczem jest rzeczywiście zatwierdzony, traktuj powstały plik i jego hasło jak dane uwierzytelniające: zaszyfrowane w spoczynku, przesłane zaufanym kanałem i usunięte, gdy rejestracja się skończy.

Weryfikuj, uwierzytelniając się importowaną tożsamością, a nie patrząc, czy import się udał. Klient, który przyjmuje publiczny certyfikat do swojego magazynu, nie dowiódł niczego o kluczu.

Zakończ potwierdzeniem, że serwer przyjmuje nową tożsamość, a stara nadal zachowuje się tak, jak zakłada polityka. W ten sposób przewodnik kończy się dowodem, a nie plikiem, który wygląda poprawnie.