Stary plik P12 zawodzi w OpenSSL 3: złe hasło czy stary szyfr?

Okno importu przyjmuje hasło, przez chwilę wiruje, a potem oznajmia, że nie potrafi odczytać pakietu. Nic w tym komunikacie nie mówi, czy fraza hasła została wpisana błędnie, czy plik zapieczętowano szyfrem, którego klient już nie dostarcza. To różne awarie z różnymi naprawami, a zły wybór prowadzi do obniżenia wersji klienta, które tylko odsuwa decyzję. Obserwacja, na którym etapie klient się zatrzymuje, rozdziela je w około minutę.

Co dzieje się między oknem dialogowym a listą certyfikatów

Plik .p12 to kontener, nie certyfikat. W środku znajduje się jedna lub więcej torebek certyfikatów i torebka klucza prywatnego zaszyfrowana kluczem wyprowadzonym z hasła, a także kontrola integralności zwana MAC obejmująca cały plik. Otwarcie oznacza weryfikację tego MAC, odszyfrowanie torebki klucza i dopasowanie certyfikatu do klucza, który wychodzi.

Kłopot z hasłem pojawia się na etapie MAC. Kłopot z szyfrem pojawia się później, gdy torebkę klucza trzeba rozpakować, a kompilacja, która to robi, nie ma implementacji algorytmu wymienionego w pliku.

Drugi przypadek jest częsty w dzisiejszych systemach, bo OpenSSL 3 przeniósł grupę starych algorytmów do opcjonalnego legacy provider. Pakiety eksportowane przez OpenSSL 1.x zwykle pieczętowały certyfikaty 40-bitowym RC2, a klucz prywatny trzykluczowym Triple DES. Domyślna kompilacja OpenSSL 3 nadal weryfikuje MAC poprawnym hasłem, a potem zawodzi na torebce, więc hasło nigdy nie było błędne i wpisanie go ponownie niczego nie zmienia.

Odczytaj kontener bez wypisywania klucza

Poproś kompilację OpenSSL na własnej maszynie o sparsowanie pliku i odczytanie miejsca, w którym się poddaje. Inspekcja bez pliku wyjściowego zostawia klucz zaszyfrowany na dysku i to jedyny powód, dla którego ten krok jest bezpieczny na współdzielonym hoście.

openssl pkcs12 -in vpn-identity.p12 -info -noout

Na starym pakiecie z poprawnym hasłem wypisuje to atrybuty torebki, a potem zatrzymuje się z digital envelope routines::unsupported. Z błędnym hasłem dostajesz Mac verify error: invalid password?, zanim odczytana zostanie jakakolwiek torebka. Oba komunikaty wskazują przeciwne kierunki i dokładnie tę informację klient zataił.

Jeśli awaria dotyczy nieobsługiwanego algorytmu, uruchom to samo polecenie ponownie z dodanym -legacy i niczym innym niezmienionym. Ta flaga ładuje legacy provider tylko dla tego jednego procesu. Nie zmusza klienta VPN do parsowania starych pakietów, nie dotyka systemowej polityki kryptograficznej i jest pomiarem, a nie naprawą, bo plik i tak trzeba wymienić.

Który błąd oznacza który etap

Krótka tabela rozdziela trzy wyniki, a sformułowanie jest ważniejsze niż miejsce, w którym pojawiło się okno.

Tekst taki jak not enough data lub header too long nie należy do żadnej z dwóch pierwszych grup. To problem formatu: plik DER przemianowany na .pem, kopia zepsuta przez edytor, który przepisał końce wierszy, albo niekompletne pobranie. Przed zajrzeniem do szyfrów porównaj sumę kontrolną z tą, którą przysłał wystawca.

Traktuj Mac verify error wyłącznie jako dowód dotyczący hasła. Oznacza, że MAC obliczony z wpisanego tekstu nie zgadza się z zapisaną wartością, co zdarza się przy literówce, przy haśle z pamięci podręcznej po wcześniejszym imporcie albo przy pliku wyeksportowanym ponownie pod inną frazą hasła. Nie mówi nic o tym, czy algorytmy w środku są stare.

Zbuduj pakiet, który klient naprawdę otworzy

Gdy parser legacy potwierdzi, że plik jest zdrowy, trwałym rozwiązaniem jest zamiennik, którego algorytmy obsługuje docelowy klient: AES-256-CBC dla torebek klucza i certyfikatów, PBKDF2 z SHA-256 do wyprowadzania i SHA-256 dla MAC. Twój administrator PKI może to wyeksportować z tego samego materiału klucza, a certyfikat w środku pozostaje tym, któremu twoje serwery już ufają.

Gdy musisz przekonwertować lokalnie, poproś narzędzie pkcs12 o ponowne zapieczętowanie torebek zamiast najpierw ich zrzucania. Trzymaj obie frazy hasła poza historią powłoki, czytając je z pliku.

openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
  -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
  -passin file:old.pass -passout file:new.pass

Udana konwersja nie mówi nic o wygaśnięciu, przeznaczeniu klucza, dopasowaniu klucza prywatnego ani o tym, czy serwer ufa łańcuchowi wystawcy. Przepakowanie to zmiana transportu, nie odnowienie, i każde z nich nadal wymaga własnego sprawdzenia.

Pomiń każdy przepis, który zapisuje niechroniony klucz pośredni lub puste hasło wyjściowe tylko dlatego, że klient przyjął potem plik. Czytelny pakiet ze zdjętą ochroną to gorszy wynik niż awaria importu, od której zacząłeś.

Potwierdź, że klient zaimportował zbudowany plik

Czyste sparsowanie w terminalu dowodzi, że kontener jest poprawny. Nie dowodzi, że klient go wybrał, bo pozostawiony profil może nadal wskazywać stary plik, a niektóre klienty buforują zaimportowaną tożsamość pod nazwą, której nie wybrałeś.

Wypisz tożsamość, którą zamierzasz zaimportować, i porównaj ją z tym, co klient pokazuje w widoku certyfikatów.

openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
  | openssl x509 -noout -subject -dates -fingerprint -sha256

Najpierw usuń nieaktualny wpis profilu, potem importuj. Jeśli klient zapisuje w logu temat albo odcisk palca, który wczytał, dopasuj go do linii powyżej; jeśli pokazuje tylko przyjazną nazwę, sprawdź zamiast tego datę ważności, bo trudniej ją pomylić z innym certyfikatem tego samego wystawcy.

Dokumentacja PKCS12 wymienia użyte tutaj provider, frazę hasła i opcje wyjściowe. Trzymanie legacy provider poza środowiskiem klienta jest sednem: mierz z nim, dostarczaj bez niego i zostaw klucz prywatny chroniony na dysku.