W tym artykule wyjaśniono, jak korzystać z certyfikatów wydanych przez zewnętrzny urząd certyfikacji (CA), taki jak Let's Encrypt, Comodo, Symantec, Digicert itp. Opisze również, jak ogólnie działają certyfikaty.
Streszczenie
Certyfikaty służą dwóm głównym celom: szyfrowaniu komunikacji między dwoma podmiotami oraz potwierdzaniu autentyczności podmiotu. Ten pierwszy może być przyznany przez tzw. certyfikat z podpisem własnym, ale do uwierzytelnienia jednostki potrzebny jest certyfikat globalnie zaufany wystawiony przez główny lub pośredni urząd certyfikacji. W tym artykule wyjaśnimy, w jaki sposób certyfikaty generalnie osiągają to uwierzytelnianie, jak zmienić format certyfikatu, aby działał z innymi urządzeniami, w tym z naszymi zaporami, jak zaimportować certyfikat do zapory i jak należy obchodzić się z certyfikatami, aby uniknąć zagrożeń bezpieczeństwa.
Spis treści
- Jak działa certyfikat?
- Certyfikaty z podpisem własnym
- Praca z certyfikatami
- Importowanie certyfikatów w firewallach USG/ATP
- Bezpieczeństwo certyfikatu
Jak działa certyfikat?
Każdy certyfikat składa się z dwóch części: certyfikatu (nazywanego również kluczem publicznym) i klucza prywatnego. Certyfikat może być publicznie udostępniany i zawiera jedynie informacje o celach, dla których certyfikat został wydany oraz dla jakiego podmiotu certyfikat został wydany – może to być Twoja nazwa FQDN, adres e-mail lub inna wartość.
Certyfikaty mają ograniczony okres ważności - pomaga to w sytuacjach, gdy jakiś stary certyfikat z kluczem prywatnym zostanie gdzieś wykopany po dziesięcioleciach. Jeśli ważność była nieskończona, certyfikat nadal mógłby być używany do złośliwych celów przez każdego, kto dostanie go w swoje ręce. Od 2021 r. nie zaleca się stosowania okresu ważności powyżej jednego roku. Wraz z pojawieniem się automatycznych mechanizmów ponownego wystawiania, takich jak CertBot, okres ten może się znacznie skrócić, aby jeszcze bardziej poprawić bezpieczeństwo.
Certyfikaty mogą zostać unieważnione w przypadku wycieku klucza prywatnego – i jako środek ostrożności, po każdym naruszeniu bezpieczeństwa polegającym na złamaniu sprzętu zawierającego klucze prywatne powinno nastąpić unieważnienie certyfikatu, a następnie ponowne wydanie nowych certyfikatów.
Certyfikaty mogą być wydawane różnym podmiotom, takim jak FQDN, E-mail, a nawet adres IP czy imię i nazwisko. Chociaż technicznie możliwe jest posiadanie certyfikatów FQDN typu wildcard i są one często preferowane przez użytkowników, należy pamiętać, że w przypadku wycieku klucza prywatnego z określonej usługi, certyfikat wildcard uwierzytelnia cały FQDN - w rezultacie wyciek klucz prywatny na serwerze WWW, który służy do prezentacji firmy, może być równie dobrze wykorzystany do ataków MITM pomiędzy serwerem Exchange lub systemem CRM. Utrzymywanie niezależnych certyfikatów dla każdej subdomeny pomaga złagodzić wpływ wycieku do momentu unieważnienia certyfikatu.
Chociaż możliwe jest również wystawianie certyfikatów na adres IP, jest to przestarzałe. Powodem tego jest to, że adresy IP można łatwo zmienić w porównaniu do FQDN.
Podstawowa zasada certyfikatów jest dość prosta. Na przykład Alicja chce uzyskać dostęp do serwera Boba, ale problem polega na tym, że nigdy jej tam nie było, więc nigdy nie mogli wymienić wspólnego sekretu w celu uwierzytelnienia. Jak Alice może mieć pewność, że rzeczywiście łączy się z Bobem? W tym momencie do gry wkracza Charlie. Alicja zna Charliego i dodała jego certyfikat do głównego repozytorium certyfikatów. Dlatego Alice uważa Charliego za zaufany podmiot. Jeśli Bob ma własny certyfikat i klucz prywatny wystawiony przez Charliego, może uwierzytelnić się przed Alicją i nie ma znaczenia, że Alicja nigdy wcześniej nie kontaktowała się z Bobem, ponieważ Karol ufa Bobowi, a ponieważ Alicja ufa Charliemu, ufa również Bobowi . To jest coś, co nazywa się łańcuchem zaufania.
Rzućmy okiem na certyfikat sieciowy Łańcucha Zaufania dla naszego Kampusu Wsparcia:
Zauważ, że istnieje również inna jednostka o nazwie R3. Nazywa się to pośrednim CA, podczas gdy DST Root CA X3 to Root CA. Certyfikat może mieć tylko jeden główny urząd certyfikacji, ale może być więcej pośrednich urzędów certyfikacji. Pośredni urząd certyfikacji to podmiot, któremu przyznano uprawnienia do wydawania certyfikatów swoim klientom. Dopóki Twój komputer ma certyfikat DST Root CA X3 na liście zaufanych certyfikatów głównych, będzie uważany za zaufany support.zyxel.eu.
Certyfikaty z podpisem własnym
Domyślnie nasze zapory (i wiele innych urządzeń) używają certyfikatów z podpisem własnym do nawiązywania zaszyfrowanego połączenia TLS. Taki certyfikat jest zgłaszany przez przeglądarkę dobrze znanym komunikatem o błędzie: 
Są dwa powody, dla których tak się dzieje. Pierwszym powodem jest to, że certyfikat jest w zasadzie certyfikatem głównego urzędu certyfikacji, który nie występuje w twoim systemie. Ale po prostu zainstalowanie go jako root CA na swoim komputerze nie załatwi sprawy, ponieważ certyfikat nie jest wystawiony dla twojego adresu IP lub domeny. Certyfikat nadaje się jednak do bezpiecznego połączenia, a korzystanie z niego nie wiąże się z żadnym zagrożeniem bezpieczeństwa, o ile jego klucz prywatny nie wycieknie - jedynym problemem jest to, że nie można potwierdzić tożsamości.
Praca z certyfikatami
Przez lata powstało wiele formatów certyfikatów. Certyfikaty jednak nadal stosują tę samą zasadę i wszystkie formaty można przekonwertować na inne formaty.
Formaty certyfikatów
Najstarszym formatem byłby PEM, który zawiera klucz zakodowany w ASCII. Powodem tego jest oryginalne użycie w zaszyfrowanych wiadomościach e-mail, w których certyfikat binarny może zostać zniekształcony. PEM są powszechne w systemach Unix i prawdopodobnie Twój CA wysłał Ci certyfikat wraz z kluczem prywatnym w formacie PEM. Zwykle używa rozszerzenia pliku .pem lub .cer.
DER to binarna forma certyfikatu w formacie ASCII PEM. Wszystkie typy certyfikatów i kluczy prywatnych mogą być zakodowane w formacie DER. Ten format obsługuje przechowywanie pojedynczego certyfikatu i nie zawiera klucza prywatnego dla pośredniego/głównego urzędu certyfikacji. Mają rozszerzenie .der lub .cer i są najczęściej używane na platformach Java.
PKCS#7 to format binarny, który umożliwia przechowywanie certyfikatów lub całego łańcucha zaufania w jednym pliku. Jednak żaden klucz prywatny nie może być przechowywany w tym formacie. Ten format jest najczęściej używany przez urzędy certyfikacji w celu zapewnienia pełnego łańcucha zaufania. Używa rozszerzenia .p7b.
PKCS#12, znany również jako PFX, to format, który może zawierać również cały łańcuch zaufania i klucz prywatny. Zazwyczaj ten format jest dostarczany przez urzędy certyfikacji, ponieważ można go zabezpieczyć hasłem. Zwykle używa rozszerzenia .p12 lub .pfx.
Narzędzia do certyfikacji
Windows ma wbudowane narzędzie systemowe CLI certutil, które można wykorzystać do konwersji certyfikatów. Wtyczki do zarządzania w Microsoft Management Console umożliwiają również zarządzanie certyfikatami.
Narzędzie open source o nazwie OpenSSL jest również w stanie obsługiwać i konwertować certyfikaty. Pliki binarne są dostępne dla systemów Windows, Linux i macOS (i wielu innych platform)
Przydatne polecenia certutil:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Przydatne polecenia OpenSSL:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Importowanie certyfikatu w firewallach USG/ATP
Obecny projekt (stan na czerwiec 2021 r.) ogranicza się do importu certyfikatów bez kluczy pośrednich. Jeśli certyfikat zawiera klucz pośredni, plik zostanie przeanalizowany nieprawidłowo, a próba użycia takiego certyfikatu może spowodować niedostępność usługi (takiej jak WebGUI). Dobrym pomysłem jest uzyskanie certyfikatu w formacie .pem i wyeksportowanie go do formatu .pfx za pomocą certutil lub OpenSSL. Certyfikat można zaimportować wraz z hasłem w następującym menu:
Configuration > Objects > Certificates > My Certificates
Bezpieczeństwo certyfikatu
Każdy certyfikat ma swój własny klucz prywatny. Chociaż certyfikat jest informacją publiczną, klucz prywatny musi być traktowany jako tajny – i nie powinien być przez nikogo udostępniany. Nawet u nas w Zyxel – jedynym prawidłowym sposobem jest użycie narzędzi zdalnej pomocy, takich jak TeamViewer. Przechowując klucz prywatny w formacie pem, sprawdź dwukrotnie uprawnienia dostępu do klucza prywatnego, aby zapobiec jego wyciekowi. Zawsze używaj szyfrowania hasła w formacie PFX, aby zapewnić przynajmniej pewien stopień bezpieczeństwa podczas eksportowania certyfikatów. Wszelkie certyfikaty z ujawnionym kluczem prywatnym należy natychmiast unieważnić.
ZRZECZENIE SIĘ:
Szanowny Kliencie, pamiętaj, że używamy tłumaczenia maszynowego, aby dostarczać artykuły w Twoim lokalnym języku. Nie wszystkie teksty mogą być przetłumaczone dokładnie. W przypadku pytań lub rozbieżności co do dokładności informacji w przetłumaczonej wersji zapoznaj się z oryginalnym artykułem tutaj: Wersja oryginalna