PKCS12, PEM czy DER: czego naprawdę potrzebuje klient VPN

W dyskusjach o certyfikatach krążą dwa twierdzenia. Pierwsze, że .p12 to mocna opcja, a .pem luźna; drugie, że plik tekstowy musi być bezpieczny do wysłania, bo można go przeczytać. Żadne nie wytrzymuje minuty sprawdzania.

PKCS12, PEM i DER opisują, jak obiekty certyfikatów są pakowane i kodowane. Nie decydują, kto jest drugą stroną, czy wystawcy można ufać ani czy plik wymaga hasła.

To, co akceptuje klient, to kwestia zgodności. To, co zawiera plik, to kwestia tożsamości. Oddziel te dwie sprawy, a większość błędów importu przestanie być tajemnicza.

Trzy kontenery, jeden model obiektów

Zacznij od tego, co naprawdę masz. Certyfikat to podpisane oświadczenie o kluczu publicznym. Klucz prywatny to osobny materiał, który dowodzi, że kontrolujesz ten klucz. Łańcuch to zbiór wystawców łączących twój certyfikat z korzeniem, któremu ufa klient. Wszystkie trzy istnieją niezależnie od pakowania.

Plik PKCS12, zwykle .p12 lub .pfx, to kontener zdefiniowany w RFC 7292, który może przenosić klucz prywatny, jeden lub więcej certyfikatów i łańcuch w jednym bloku chronionym hasłem, z aliasem nazywającym tożsamość. Plik PEM to oprawa tekstowa zdefiniowana w RFC 7468: treść base64 między wierszami BEGIN i END, a jeden plik może zawierać kilka bloków pod rząd. DER to binarne kodowanie tych samych struktur ASN.1, a treść PEM to dosłownie DER owinięty base64.

To ostatnie zdanie warto zapamiętać. Konwersja PEM do DER przepisuje oprawę, nie zawartość, a konwersja odwrotna zwraca oryginalne bajty.

Kodowanie to nie szyfrowanie

base64 to alfabet transportowy. Nic nie ukrywa i każdy może zdekodować blok PEM w powłoce. Plik DER jest binarny i równie publiczny. Żadna z tych cech nie jest ochroną i żadna nie sugeruje istnienia hasła.

Prawdziwa ochrona tkwi w materiale klucza. Pakiet PKCS12 może szyfrować zawartość kluczem wyprowadzonym z hasła. Prywatny klucz PEM można zaszyfrować starym blokiem nagłówka lub trzymać w PKCS#8 EncryptedPrivateKeyInfo. Sam certyfikat nie zawiera niczego tajnego, dlatego eksport, który dał tylko certyfikat, zostawia klienta bez możliwości uwierzytelnienia, niezależnie od formatu opakowania.

Rozszerzenie to podpowiedź, nie umowa. Pliki kończące się na .cer i .crt występują w obu kodowaniach, a urządzenia dość często eksportują certyfikaty DER pod nazwami .pem, że zgadywanie po sufiksie kosztuje popołudnie. Czytaj raczej pierwsze bajty: plik PEM otwiera wiersz BEGIN, a DER zaczyna się od 0x30, bo strukturą zewnętrzną jest SEQUENCE.

Dlaczego import naprawdę zawodzi

Komunikaty błędów klienta wciskają kilka różnych problemów w jedno zdanie o nieprawidłowym certyfikacie, więc rozdziel je według przyczyny. Najczęstsza jest niezgodność kodowania: klient parsujący PEM zwraca błąd parsowania na pliku DER, a rozwiązaniem jest konwersja, nie nowy certyfikat. Druga to brakujący klucz, gdy certyfikat jest w porządku, a tożsamości nie da się udowodnić. Trzecia to łańcuch, gdy pakiet bez certyfikatu pośredniego wygląda poprawnie w oknie importu, a zawodzi podczas uzgadniania.

Parametry szyfrowania powodują czwartą i wygląda ona dokładnie jak złe hasło. Starsze urządzenia eksportowały pliki PKCS12 z RC2-40 i 3DES, których OpenSSL 3 odmawia, jeśli nie wczytano dostawcy legacy. Ponowny eksport z urządzenia z AES-256-CBC i PBKDF2 to trwałe rozwiązanie. Pozostawianie starych szyfrów na stałe włączonych na komputerze klienta dla jednego pliku to zły interes.

Piąta to niejednoznaczność. Kontener z dwoma kluczami i dwoma certyfikatami albo plik PEM z trzema blokami CERTIFICATE zmusza klienta do wyboru, a jego wybór to często po prostu pierwszy element. Gdy tunel wstaje z niewłaściwą tożsamością, zwykle jest to przyczyną.

Sprawdź przed konwersją

Czytaj strukturę bez drukowania sekretów. openssl pkcs12 -in bundle.p12 -info -noout raportuje algorytmy szyfrowania i aliasy, tłumiąc wyjście klucza i certyfikatu, a podręcznik openssl-pkcs12 dokumentuje flagi. Usunięcie -noout i dodanie -nodes służy tworzeniu plików, które zamierzasz zachować, a nie szybkiemu rzutowi oka, bo zapisuje klucz prywatny jawnie.

Dla certyfikatu openssl x509 -in cert.pem -noout -subject -issuer -dates odpowiada na to, na co nie odpowie okno importu, a dodanie -ext subjectAltName pokazuje nazwy, dla których certyfikat jest naprawdę ważny. Jeśli plik jest DER, dodaj -inform DER; ta jedna flaga rozwiązuje większość błędów unable-to-load.

Dopasowanie klucza do certyfikatu jest mechaniczne i warto je wykonać przed każdym importem:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

Identyczne skróty oznaczają, że para do siebie pasuje. Różne skróty oznaczają, że masz zły klucz, i żadna konwersja formatu tego nie zmieni.

Czego format nigdy nie zmienia

Decyzje o zaufaniu zapadają ponad kontenerem. Klient przechodzi łańcuch do korzenia w swoim magazynie, sprawdza okno ważności, sprawdza rozszerzone użycie klucza do uwierzytelniania klienta, a po stronie serwera sprawdza, czy nazwa, do której zadzwonił, występuje w certyfikacie. Żaden z tych kroków nie czyta rozszerzenia pliku.

Dlatego zmiana nazwy pliku, aż błąd zniknie, jest tak niezawodnym sposobem tracenia czasu. Import się udaje, tożsamość nadal jest błędna, a błąd wraca podczas uzgadniania, gdzie komunikat jest mniej pomocny. Dlatego też pakiet wyeksportowany dwa lata temu importuje się czysto i mimo to jest odrzucany: data ważności podróżowała w certyfikacie, nie w nazwie pliku.

Kolejność, która unika przeróbek

Zapytaj dokumentację klienta, jakie kodowania akceptuje i jakiego kontenera oczekuje dla tożsamości klienta, a potem zobacz, co ci dano. Jeśli klient chce jednej importowalnej tożsamości, a masz osobne pliki PEM, zbuduj pakiet raz z hasłem, które kontrolujesz, i zachowaj źródła. Jeśli chce PEM, wyodrębnij klucz i łańcuch, a następnie usuń pliki pośrednie procesem obsługi poświadczeń, którego twój zespół już używa.

Po imporcie sprawdź tożsamość, nie okno: podmiot, wystawcę, ważność i nazwę, którą klient przedstawi. Ładna nazwa na liście to etykieta, nie zweryfikowana tożsamość. Jeśli potem tunel zawiedzie, debugujesz uwierzytelnianie lub trasowanie zamiast pakowania, co jest znacznie krótszą rozmową.