Przenoszenie certyfikatów i kluczy

Przenoszenie certyfikatów i kluczy wymaga eksportu z hasłem ochronnym i importu na docelowym serwerze.

Zakres przenoszonych elementów i ich role

Przenoszenie certyfikatów i kluczy polega na odtworzeniu na innym komputerze lub serwerze zestawu danych używanych do uwierzytelniania, szyfrowania albo podpisu cyfrowego. Certyfikat X.509 zawiera między innymi klucz publiczny, nazwę podmiotu, nazwę wystawcy, okres ważności oraz podpis urzędu certyfikacji. Sam certyfikat nie pozwala jednak udowodnić, że urządzenie posiada tożsamość przypisaną do klucza. Do tego potrzebny jest odpowiadający mu klucz prywatny.

Klucz prywatny powinien być traktowany jako tajny materiał kryptograficzny. W przypadku certyfikatu TLS jego obecność na docelowym urządzeniu umożliwia serwerowi potwierdzenie tożsamości podczas ustanawiania połączenia HTTPS. Przy certyfikatach podpisu elektronicznego lub szyfrowania klucz prywatny może być używany do składania podpisów albo odszyfrowywania danych. Certyfikat, klucz prywatny i certyfikaty pośrednie tworzą więc komplet, którego elementów nie należy przypadkowo rozdzielać.

Eksport do bezpiecznego pliku

Najczęściej certyfikat wraz z kluczem prywatnym eksportuje się do kontenera PKCS#12, zwykle zapisywanego jako plik z rozszerzeniem .p12 albo .pfx. Taki kontener może zawierać certyfikat użytkownika lub serwera, odpowiadający mu klucz prywatny oraz certyfikaty pośrednie potrzebne do zbudowania łańcucha zaufania. Podczas eksportu należy zaznaczyć opcję obejmującą klucz prywatny, jeżeli celem jest pełne odtworzenie konfiguracji. Eksport samego certyfikatu publicznego nie przeniesie prawa do posługiwania się daną tożsamością kryptograficzną.

Plik PKCS#12 powinien zostać zabezpieczony silnym, unikalnym hasłem ochronnym. Hasło należy przekazać innym kanałem niż sam plik, a po zakończeniu importu usunąć niezaszyfrowane kopie z katalogów tymczasowych, poczty elektronicznej i nośników przenośnych. Nie wolno zakładać, że zmiana rozszerzenia pliku albo spakowanie go do archiwum zastępuje szyfrowanie. Jeżeli klucz prywatny był wcześniej przechowywany bez ochrony lub mógł zostać skopiowany przez nieuprawnioną osobę, samo ponowne zabezpieczenie kontenera nie unieważnia wcześniejszego ryzyka.

Import, łańcuch zaufania i kontrola działania

Na urządzeniu docelowym należy zaimportować kontener do właściwego magazynu certyfikatów. Systemy operacyjne i aplikacje mogą rozdzielać magazyny użytkownika, komputera lokalnego, przeglądarki oraz konkretnej usługi, dlatego certyfikat widoczny po zalogowaniu na konto użytkownika nie zawsze będzie dostępny dla procesu uruchomionego jako usługa. W czasie importu trzeba potwierdzić, że certyfikat wskazuje ten sam klucz publiczny, który odpowiada importowanemu kluczowi prywatnemu. Aplikacja zwykle sygnalizuje obecność klucza prywatnego odpowiednią ikoną lub komunikatem.

Po imporcie należy sprawdzić datę rozpoczęcia i zakończenia ważności, nazwę podmiotu, przeznaczenie klucza oraz alternatywne nazwy DNS zapisane w certyfikacie. Dla połączeń TLS ważne jest również dołączenie certyfikatów pośrednich. Brakujący element łańcucha może powodować ostrzeżenia w przeglądarkach, klientach pocztowych albo programach korzystających z bibliotek kryptograficznych, mimo że sam certyfikat serwera jest formalnie ważny. Warto wykonać test w aplikacji, która korzysta z certyfikatu, i sprawdzić dzienniki pod kątem błędów dostępu do klucza, niezgodności hasła, niewłaściwego magazynu lub braku zaufania do wystawcy.

Jeżeli klucz prywatny jest chroniony dodatkowymi uprawnieniami, konto uruchamiające aplikację musi mieć możliwość użycia klucza, ale niekoniecznie jego eksportu. Nadawanie pełnych uprawnień wszystkim użytkownikom zwiększa ryzyko skopiowania klucza. Po pomyślnym teście należy zweryfikować, czy stary komputer nie jest nadal używany do obsługi tej samej usługi oraz czy mechanizm odnowienia certyfikatu został skonfigurowany na nowym urządzeniu. Przeniesienie pliku nie przenosi automatycznie ustawień aplikacji, wpisów w magazynie zaufania ani konfiguracji zapory sieciowej.

Przenoszenie certyfikatów w praktyce serwisowej

Przed rozpoczęciem operacji warto ustalić, czy użytkownik potrzebuje certyfikatu do logowania, podpisywania dokumentów, szyfrowania plików, dostępu do sieci, czy obsługi połączenia HTTPS. Różne zastosowania mogą wymagać innych formatów i innych magazynów. Nie każdy certyfikat można bezpiecznie wyeksportować: część kluczy jest generowana w urządzeniu kryptograficznym, na karcie inteligentnej albo w module TPM i została oznaczona jako nieeksportowalna. W takim przypadku przenosi się certyfikat publiczny lub instaluje odpowiedni nośnik oraz sterownik, ale nie kopiuje klucza prywatnego jako zwykłego pliku.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a przy czynnościach związanych z certyfikatami może pomóc w przygotowaniu kopii zapasowej, identyfikacji właściwego magazynu oraz sprawdzeniu działania aplikacji po imporcie. Operację należy wykonywać po potwierdzeniu prawa do używania certyfikatu i znajomości hasła eksportu. Po zakończeniu serwis powinien pozostawić użytkownikowi jasną informację o lokalizacji certyfikatu, zastosowanych zabezpieczeniach i konieczności odnowienia certyfikatu przed końcem jego ważności.

Jeżeli certyfikat lub klucz prywatny zaginął, został ujawniony albo trafił na niekontrolowany komputer, właściwą reakcją jest kontakt z wystawcą i rozważenie unieważnienia certyfikatu. Nowy certyfikat wystawiony na nową parę kluczy usuwa zależność od potencjalnie skopiowanego klucza. Samo usunięcie pliku z jednego komputera nie gwarantuje usunięcia wszystkich kopii, dlatego po incydencie trzeba przeanalizować nośniki, kopie zapasowe i katalogi tymczasowe, a następnie wdrożyć nowy materiał kryptograficzny.