Dlaczego kopiowanie ca.key na każdego klienta VPN psuje CA

Gdzieś w instrukcji instalacji cały katalog jest kopiowany w całości na każdego laptopa, bo to było prostsze niż zdecydowanie, które pliki powinny się tam znaleźć. Ten katalog zawiera ca.key, a w chwili, gdy trafi na drugie urządzenie, urząd certyfikacji przestaje być urzędem. Każdy posiadacz może teraz wydawać tożsamości, którym zaufa reszta sieci.

Warto raz rozpłatać to zamieszanie, bo oba pliki wyglądają podobnie, a robią rzeczy przeciwne.

Materiał weryfikacyjny i materiał podpisujący

Klient potrzebuje publicznego certyfikatu CA, aby sprawdzić, że certyfikat przedstawiony przez drugą stronę został podpisany przez ten urząd. To zadanie weryfikacji i nie wymaga żadnego sekretu. Podpisanie certyfikatu drugiej strony to inne zadanie, wykonywane raz przez tego, kto prowadzi CA, kluczem prywatnym, który nigdy nie opuszcza swojego chronionego magazynu. Rozdzielenie tych dwóch zadań to cały sens dostarczania dwóch plików.

Tak więc ca.crt należy do profilu, a ca.key nie należy nigdzie w jego pobliżu. Nazwy plików są konwencją, nie gwarancją, dlatego typ trzeba obejrzeć, a nie wywnioskować z nazwy.

Architektura z CA pośrednim lub usługą wydawania online nie jest tu wyjątkiem. To zwykły sposób trzymania możliwości podpisywania z dala od punktów końcowych przy jednoczesnym wydawaniu certyfikatów urządzeń na dużą skalę.

Co klient ma udowodnić własnym kluczem

Każde urządzenie otrzymuje własną parę kluczy i własny certyfikat, podpisany raz przez CA. Klient przedstawia ten certyfikat i dowodzi posiadania pasującego klucza prywatnego, a serwer decyduje, czy go przyjąć. To jest tożsamość, którą unieważnia się po zgubieniu laptopa.

Kontrast ma największe znaczenie po kradzieży. Przy tożsamościach na urządzenie jedno ujawnione urządzenie usuwa się przez unieważnienie lub przez usunięcie drugiej strony, a reszta floty działa dalej.

Wyciekłego klucza urzędu nie da się tak potraktować. Każdy certyfikat, który kiedykolwiek podpisał lub mógł podpisać, staje się podejrzany, więc odpowiedzią jest wymiana zaufania, a nie jedno unieważnienie. To projekt, nie zgłoszenie.

Przeczytaj plik, zanim go gdziekolwiek skopiujesz

Dwie komendy powiedzą ci, jakiego rodzaju obiekt trzymasz w ręku, nie wypisując żadnego sekretu. Pierwsza podaje podmiot i flagę CA na certyfikacie; druga weryfikuje klucz i podaje jego typ. Uruchom obie na plikach w pakiecie, który zamierzasz rozprowadzać. Wszystko, co weryfikuje się jako klucz prywatny, nie należy do katalogu klienta.

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

Jeśli druga komenda powiedzie się na pliku leżącym w pakiecie klienta, zatrzymaj się i uznaj pakiet za naruszony. Wynik mówiący, że klucz jest ważny, mówi też, że jest obecny, a obecność to cały problem.

Zauważ też kierunek przeciwny: profil klienta zgodnie z prawem zawiera własny klucz prywatny tego klienta. Usunięcie każdego znalezionego klucza zrywa połączenie, niczego nie poprawiając, więc obiekt trzeba zidentyfikować przed usunięciem.

Opanowanie klucza, który już rozprowadziłeś

Nie zakładaj, że usunięcie lokalnej kopii odwraca ekspozycję. Każdy, kto miał plik, mógł go skopiować, a bezpiecznym założeniem jest, że to zrobił. Postępuj zgodnie z procedurą incydentową operatora i wymień kotwicę zaufania, wydając ponownie certyfikaty urządzeń pod nowym CA.

Potem zmień pakowanie, które stworzyło problem. Wysyłaj listę katalogu z jawną listą dozwolonych plików, trzymaj klucz CA na maszynie, która nigdy nie dołącza do floty klientów, i zapisuj, który system go przechowuje.

Jeśli urząd musi wydawać często, przenieś podpisywanie za usługę lub pośrednika o wąskim zakresie i krótkiej ważności. Dzięki temu przyszły błąd ujawni podzbiór wydawania, a nie korzeń zaufania całego wdrożenia.