Wstęp

No i znowu mamy niełatwy temat. Poruszaliśmy już szyfrowanie symetryczne i asymetryczne, Klucz infrastruktury oraz masę innych tematów. Dziś jednak wrócimy troszkę do kluczy, bo na pewno się z nimi spotkasz w pracy.

Już wiesz, na czym polega klucz publiczny i prywatny, a jeśli nie, to zapraszam Cię tu. Przeczytaj, a następnie wróć do tego artykułu.

Certyfikat to plik, w którym przechowywany jest klucz publiczny

Certyfikat to plik, w którym przechowywany jest klucz publiczny i jego przypisanie do konkretnej osoby bądź organizacji. Czasem zdarza się, że certyfikat zawiera też klucz prywatny, ale nie o tym teraz.

Dla przykładu, jeśli posiadam stronę i chce zabezpieczyć ruch między stroną a Tobą, muszę posiadać klucz publiczny. Dostaję certyfikat, który zawiera ten klucz publiczny wraz z informacją, że jest on przypisany do mnie. Teraz muszę zamieścić go na serwerze, by móc zaszyfrować połączenie.

Certyfikat zawiera poniższe:

• Public key Klucz publiczny osoby bądź organizacji, która jest właścicielem certyfikatu.
• Algorithm Asymetryczny algorytm wykorzystany przez certyfikat.
• Serial number Unikalny numer przypisany do certyfikatu.
• Subject Nazwa właściciela certyfikatu.
• Issuer Informacja, kto stworzył certyfikat (nie zawsze to ta sama osoba, co właściciel).
• Valid from Odkąd obowiązuje certyfikat.
• Valid to Kiedy wygasa ważność certyfikatu.
• Thumbprint algorithm Algorytm wykorzystany do stworzenia haszu certyfikatu.
• Thumbprint Wartość hasza

Przykładowy certyfikat poniżej:

Typy Certyfikatów – Wildcard / SAN / Code signing / Self-signed

Jest mnóstwo różnych certyfikatów. Każdy z nich wykorzystywany jest w specyficznej sytuacji. Dla przykładu certyfikat email będzie wykorzystywany tylko do szyfrowania wiadomości email. Poniżej lista różnych certyfikatów:

• Wildcard To specjalny certyfikat, któremu nadawana jest standardowa nazwa. Ten certyfikat można na przykład przypisać do wielu url w obrębie domeny. Na przykład, gdybym wygenerował wildcard dla pushsec, wyglądałby on tak : *.pushsec.pl i mógłbym go użyć do www.pushsec.pl, mail.pushesc.pl, login.pushsec.pl czy do jakiegokolwiek innego adresu url w obrębie domeny.
• SAN (Subject Alternative Name) Ten certyfikat pozwala na użycie wielu naraw przypisanych do certyfikatu. Przydatne jest to wtedy, gdy serwer wykorzystuje wiele serwisów, a każdy z nich ma własną nazwę. Bez niego trzeba by stworzyć oddzielne certyfikaty.
• Code signing Służy on do podpisania kodu aplikacji, którą stworzyłeś. Jeśli nadasz certyfikat kodowi, który stworzyłeś, oznaczasz tym samym, od kogo on pochodzi, kto jest jego twórcą itp.
• Self-signed W infrastrukturze klucza publicznego każda jednostka potrzebuje certyfikatu. Jest on wykorzystywany przez root CA. Root CA tworzy swój własny certyfikat, dlatego nazywa się self-signed.

Typy Certyfikatów – Computer / Email / User / Root

• Computer Jeśli chcemy szyfrować komunikację między komputerami w infrastrukturze czy też między serwerami, każda z tych maszyn będzie musiała mieć swój certyfikat, czyli machine certificate.
• Email Certyfikat wykorzystywany z S/MIME. Klient e-mail musi zostać skonfigurowany, by wykorzystać certyfikat.
• User Tak samo jak w wypadku komputera, tak i użytkownik musi mieć certyfikat. Można go wykorzystać na przykład do zaszyfrowania pliku za pomocą EFS, czyli Encryption File System.
• Root Pierwszy serwer certyfikacyjny nazywany jest Root CA. Root CA ma swój certyfikat, którym opisuje wszystkie pozostałe, dlatego że on jest pierwszym serwerem certyfikacyjnym. Od razu powinieneś zobaczyć, że jest to szczególna jednostka, na którą musisz zwracać dużą uwagę ;).

Typy Certyfikatów – Domain Validation / Extended Validation

• Domain Validation Jest to certyfikat wykorzystywany do komunikacji SSL/TLS . Weryfikuje, czy należysz do domeny.
• Extended Validation Jest zbudowany na powyższym, ale nie tylko weryfikuje domenę, ale również sprawdza też informację z pola organizacji i potwierdza, czy to jest to.

Formaty Certyfikatów

Poza typami certyfikatów mamy też ich różne formaty.

• DER/CER (Distinguished Encoding Rule/Canonical Encoding Rule) To plik binarny używany do przechowywania informacji z certyfikatu. Mogą mieć rozszerzenia .cer bądź .der. Przykładem może być certyfikat, który ściągasz konfigurując Burp pod Firefoxem.
• PEM (Privacy-enhanced Electronic Mail) To plik w formacie ASCII zaczynający się na —–BEGIN CERTIFICATE—– i kończący na —–END CERTIFICATE—– . Wykorzystuje on rozszerzenia pliku takie, jak .pem, .crt, .cer czy .key
• PFX/P12( Personal Information Exchange) P12 służy do iportowania i exportowania certyfikatów w Windows. Rozszerzenia to .pfx i p12.
• P7B Znany również jako PKCS#7 korzysta z ASCII, by przechowywać dane z certyfikatu. Rozszerzenia to .p7b oraz .p7c. Gdy go otworzysz, wygląda podobnie jak .pem na początku i na końcu, z tą różnicą, że zamiast słowa certificate jest pkcs7.

Publiczny a prywatny serwer certyfikacyjny

• Andrzej: No tyle dowiedziałem się o tych certyfikatach, a nadal nie wiem, skąd pochodzą.
• Pusz: Certyfikaty tworzone są w CA, czyli Certificate Authorities. Są one odpowiedzialne za ich tworzenie i zarządzanie nimi.
• Andrzej: Yhm i co dalej?
• Pusz: Są dwa typy takich CA.

Pierwszym jest Public CA, wykorzystywany do tego, by potwierdzić ważność CA, które wydają certyfikaty innym. Po to, by te certyfikaty mogły być wykorzystane w aplikacji. Plusem publicznego CA jest to, że większość aplikacji ufa takim certyfikatom.

Drugim rodzajem jest Private CA. W tym wypadku, jeśli organizacja zdecyduje się na własną infrastrukturę klucza publicznego, musi stworzyć swój własny serwer CA. Mogą wtedy sami generować certyfikaty dla organizacji.

Plusem tego rozwiązania jest to, że organizacja nie musi płacić za certyfikaty. Ale trzeba pamiętać, że muszą tutaj być osoby, które będą zarządzać tą infrastrukturą, co generuje koszty.

Nieważne, czy sam stworzysz infrastrukturę, czy ją kupisz – musi być odpowiednia hierarchia. Pierwszy jest zawsze Root CA, następnie są dwa Subordinate CA lub więcej root podpisuje główny certyfikatem.

Czyli własny jak i poniższe CA, czyli subordinate CA wiec komunikacja powinna być tylko pomiędzy Subordinate CA i rootem CA nie między klientem i rootem CA.

Hierarchia:

Root CA => Subordinate CA => Twój komputer

Włączony/wyłączony serwer certyfikacyjny

Jednym z głównych powodów posiadania Subordinate CA jest możliwość wyłączenia Root CA. To znaczy odpięcia Root CA od sieci, by napastnik nie mógł się do niego dostać. W wypadku przejęcia serwera certyfikacyjngo wszystkie certyfikaty poniżej są nic niewarte, czy to będzie Root CA, czy Subordinate CA.

W wypadku przejęcia przez napastnika Root CA musisz odtworzyć całą infrastrukturę. Dlatego, gdy już wydzielisz na każdą lokalizację Subordinate CA, możesz wyłączyć Root. Gdy zaś zostanie przejęty tylko Subordinate CA, wystarczy stworzyć nowy certyfikat dla Subordinate CA i rozpopulować go na wszystkie maszyny przypisane do właśnie tego Subordinate CA.

Akceptacja certyfikatów

RA, czyli Registration Authority jest bardzo ważnym komponentem infrastruktury klucza publicznego. Odpowiada on za akceptację certyfikatów od klientów i potwierdzenie jednostki proszącej o certyfikat. RA przejdzie przez ustaloną politykę bezpieczeństwa i nada certyfikat każdemu pracownikowi i komputerowi. Jak już przejdzie tę procedurę, potwierdzony request jest wysyłany do CA i tworzy certyfikat.

Podsumowanie

Dziś dowiedziałeś się jak wyglądają certyfikaty, czym są, jakie mamy ich typy oraz jakie mają one rozszerzenia. Dowiedziałeś się również, jak wygląda publiczna infrastruktura klucza i wszystkie terminy z nim związane.

Wiem, że jak zwykle było tego troszkę, ale mam nadzieję, że pilnie się uczysz i masz już dzięki moim artykułom pokaźną bazę wiedzy. Przeszliśmy już przez masę tematów. W następnym artykule poruszę zarządzanie infrastrukturą PKI, więc przeczytaj dokładnie ten artykuł.

Pozdrawiam – Pusz