Eksport certyfikatów z P12 bez klucza prywatnego

Zgłoszenie do pomocy technicznej pyta, który certyfikat znajduje się w pakiecie VPN, a pierwszym odruchem jest wyeksportowanie wszystkiego i załączenie. Plik P12 pakuje certyfikaty i materiał klucza prywatnego w jednym kontenerze, więc wyeksportowanie wszystkiego jest dokładnie tym, czego nie należy wysyłać. Polecenie, które odpowiada na pytanie, jest problemem wyboru, a nie konwersji. Cztery przełączniki decydują, którą połowę kontenera otrzymasz, i dwa z nich brzmią bezpieczniej, niż są.

Zacznij od przeczytania kontenera, zamiast go opróżniać.

Co faktycznie zawiera plik PKCS12

Kontener PKCS12 zawiera jeden lub więcej certyfikatów, ewentualnie klucz prywatny oraz message authentication code nad zawartością. Certyfikaty mogą obejmować certyfikat liścia Twojej tożsamości klienta i certyfikaty pośrednie, które łączą go z CA. Klucz, gdy jest obecny, jest tym, co czyni plik tajemnicą, a nie dokumentem.

Ta różnica jest powodem, dla którego istnieje -nokeys i dlaczego jest to przełącznik potrzebny w tym zadaniu.

Przeczytaj pakiet bez wypisywania klucza

Forma inspekcji wypisuje strukturę i szczegóły algorytmów i niczego nie zapisuje: openssl pkcs12 -in client.p12 -info -noout. Pyta o hasło importu, które jest właściwym miejscem na tę wartość, i informuje, czy plik w ogóle zawiera klucz. Użyj -passin env:PKCS12_PASS, gdy hasła nie można wpisać, ponieważ hasło w poleceniu powłoki jest hasłem na liście procesów. Ten krok niczego nie eksportuje i o to właśnie chodzi.

Odczytaj z danych wyjściowych trzy rzeczy: ile jest certyfikatów, czy obecny jest klucz i jakie algorytmy go chronią.

Użyj -nokeys i nie myl tego z -nocerts

-nokeys wyklucza klucze prywatne i pozostawia certyfikaty. -clcerts zawęża to do certyfikatów klienta, -cacerts zawęża to do certyfikatów CA, a te dwa są filtrami, a nie alternatywami. -nocerts brzmi jak bezpieczna pisownia tego samego pomysłu i znaczy coś przeciwnego: brak certyfikatów, co pozostawia tylko klucze. Wmieszanie go do eksportu certyfikatów to sposób, w jaki klucz prywatny trafia na dysk.

Dwuwierszowa forma, która tworzy plik certyfikatów i plik CA i nic więcej, wygląda tak:

openssl pkcs12 -in client.p12 -nokeys -clcerts -out client-certificates.pem
openssl pkcs12 -in client.p12 -nokeys -cacerts -out ca-certificates.pem

Starsze pakiety wymagają -legacy w OpenSSL 3, aby odczytać swoje starsze szyfrowanie, a ten przełącznik zmienia to, co akceptuje parser, a nie to, co emituje. Jeśli parsowanie kończy się błędem o nieobsługiwanym algorytmie, dodanie -legacy jest właściwym pierwszym krokiem, a pominięcie sprawdzenia MAC nie.

Sprawdzaj dane wyjściowe, nie kod wyjścia

Zerowy status wyjścia mówi, że polecenie się wykonało, a nie że plik zawiera to, czego oczekujesz. Policz certyfikaty w danych wyjściowych i odczytaj subject oraz daty: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. Porównaj odcisk palca z tym, którego oczekuje zespół pomocy technicznej, ponieważ pakiet z dwoma certyfikatami klienta tworzy plik z dwoma blokami, a większość narzędzi czyta tylko pierwszy. Przeznaczenie, zaufanie i zgodność klucza to znowu osobne testy.

Certyfikat, który się parsuje, jest certyfikatem, który się parsuje. To nie jest certyfikat, który akceptuje VPN.

Zdecyduj, czy w ogóle potrzebujesz plików

Jeśli klient odbierający importuje PKCS12 bezpośrednio, wysłanie oryginalnego pakietu zatwierdzonym kanałem z hasłem trzymanym osobno jest prostsze i zachowuje ochronę. Wyodrębnianie służy do inspekcji, dla klienta, który potrzebuje PEM, lub dla sprawy pomocy technicznej, która poprosiła o konkretny artefakt. Każde wyodrębnienie usuwa jedną warstwę i powinno mieć powód.

Certyfikaty publiczne nie zawierają klucza prywatnego, ale zawierają nazwy i dane organizacji. Udostępniaj pola, o które prosiło zgłoszenie, zamiast pliku, chyba że poproszono właśnie o plik.