Manu

PKI i Certyfikaty SSL/TLS - Czym Są, Po Co, Jak Tworzyć?

PKI i Certyfikaty SSL/TLS: Poradnik dla Każdego - Czym Są, Po Co, Jak Tworzyć?
Czy kiedykolwiek zastanawiałeś się, dlaczego strony internetowe mają kłódkę w przeglądarce, a Twoje dane są bezpieczne podczas zakupów online? To zasługa Certyfikatów SSL/TLS i stojącej za nimi infrastruktury PKI! To jak cyfrowy paszport i system jego wydawania – pomagają potwierdzić tożsamość w internecie i zapewniają, że nikt nie podsłuchuje Twojej rozmowy. Zanurzmy się w świat cyfrowego zaufania!
Co to jest? Jak to zrozumieć?
1. Co to jest PKI? (Infrastruktura Klucza Publicznego)

PKI (Public Key Infrastructure) to taki "cyfrowy system zaufania" w internecie. To zestaw zasad, technologii i instytucji, które razem pozwalają nam bezpiecznie komunikować się i wymieniać dane, wiedząc, że rozmawiamy z tym, z kim myślimy, że rozmawiamy.

Analogia: Wyobraź sobie system paszportowy na całym świecie. PKI to jak ten system, który pozwala sprawdzić, czy paszport jest prawdziwy, czy został wydany przez uprawniony urząd i czy jego właściciel to faktycznie ta osoba, za którą się podaje. Dzięki temu możemy ufać, że osoba z paszportem jest tym, za kogo się podaje, nawet jeśli nigdy jej nie spotkaliśmy.

W skrócie, PKI rozwiązuje problem: "Jak mogę ufać komuś, kogo nie znam, w świecie cyfrowym?".

2. Co to jest Certyfikat Cyfrowy (SSL/TLS)?

Certyfikat cyfrowy (często nazywany certyfikatem SSL lub TLS, choć TLS to nowsza technologia) to nic innego jak cyfrowy dowód tożsamości. Zawiera informacje o właścicielu (np. strona internetowa, serwer, osoba), jego klucz publiczny (o tym za chwilę) oraz cyfrowy podpis zaufanej instytucji (Urzędu Certyfikacji).

Analogia: Certyfikat to jak Twój dowód osobisty lub paszport. Zawiera Twoje dane (imię, nazwisko, data urodzenia) i zdjęcie. Jest podpisany przez wiarygodną instytucję (urząd miasta/państwo), co potwierdza, że jest prawdziwy.

Kiedy łączysz się ze stroną internetową z "kłódką", przeglądarka sprawdza jej certyfikat. Jeśli certyfikat jest ważny i podpisany przez zaufany urząd, przeglądarka wie, że strona jest tym, za co się podaje i może bezpiecznie nawiązać połączenie.

3. Klucze Publiczne i Prywatne: Podstawa Bezpieczeństwa

Certyfikaty opierają się na tzw. kryptografii klucza publicznego, gdzie każda "osoba" (serwer, użytkownik) ma parę kluczy:

  • Klucz Publiczny: Jest jak numer telefonu lub adres e-mail. Możesz go śmiało rozdawać każdemu. Służy do szyfrowania danych, które mają dotrzeć tylko do Ciebie, oraz do weryfikacji Twojego cyfrowego podpisu.
  • Klucz Prywatny: Jest jak Twój klucz do skrzynki pocztowej. Musisz go trzymać tylko dla siebie i nikomu nie udostępniać! Służy do odszyfrowywania danych zaszyfrowanych kluczem publicznym oraz do tworzenia cyfrowych podpisów.

Analogia: Klucz publiczny to otwarta kłódka, którą możesz dać każdemu. Ktoś zakłada tę kłódkę na swoją wiadomość, zamyka ją (szyfruje) i wysyła do Ciebie. Tylko Ty masz klucz prywatny, który pasuje do tej kłódki, więc tylko Ty możesz ją otworzyć (odszyfrować).

A podpis? Gdy podpisujesz dokument (szyfrujesz go swoim kluczem prywatnym), każdy może użyć Twojego klucza publicznego, by sprawdzić, czy podpis jest prawdziwy i pochodzi od Ciebie. Jeśli klucz publiczny pasuje, to wiesz, że to na pewno Ty podpisałeś dokument i że nikt go nie zmienił po drodze.

4. Urząd Certyfikacji (CA): Strażnik Zaufania

Urząd Certyfikacji (Certificate Authority - CA) to instytucja, której ufasz, że sprawdzi tożsamość osoby/firmy i cyfrowo podpisze jej certyfikat. Przeglądarki internetowe i systemy operacyjne mają wbudowaną listę zaufanych CA (np. DigiCert, Let's Encrypt, Sectigo).

Analogia: Urząd Certyfikacji to jak Urząd Miasta lub Ministerstwo Spraw Wewnętrznych, które wydaje dowody osobiste i paszporty. Ufasz im, że zweryfikowali Twoją tożsamość, zanim wystawili dokument. Podobnie, jeśli przeglądarka widzi certyfikat podpisany przez zaufane CA, wie, że może ufać stronie internetowej.

Możesz też stworzyć własne CA (tzw. Self-Signed CA), ale wtedy tylko Ty (lub osoby, które celowo dodadzą Twoje CA do swoich "zaufanych" list) będziecie ufać certyfikatom wydanym przez Twoje CA.

5. Rodzaje Certyfikatów (i do czego służą)
  • Certyfikaty SSL/TLS dla stron WWW: To te, które widzisz w przeglądarkach (zielona kłódka). Potwierdzają tożsamość strony i szyfrują ruch między Tobą a serwerem.
  • Certyfikaty do podpisywania kodu (Code Signing): Deweloperzy używają ich do podpisywania swoich programów. Dzięki temu wiesz, że program pochodzi od konkretnego twórcy i nie został zmieniony przez osoby trzecie.
  • Certyfikaty e-mail (S/MIME): Służą do szyfrowania i cyfrowego podpisywania wiadomości e-mail, zapewniając ich poufność i autentyczność.
  • Certyfikaty klienckie (Client Certificates): Używane do uwierzytelniania użytkowników lub urządzeń. Zamiast loginu i hasła, komputer przedstawia swój certyfikat, aby udowodnić, kim jest.
  • Certyfikaty CA (Certificate Authority Certificates): To certyfikaty samych Urzędów Certyfikacji. Są podstawą łańcucha zaufania.
6. Jak Stworzyć Własne Certyfikaty (Self-Signed) - OpenSSL

Możesz tworzyć własne certyfikaty za darmo, np. za pomocą narzędzia OpenSSL. Takie certyfikaty nazywane są "self-signed" (samopodpisane) lub "wewnętrznymi". Są przydatne w środowiskach testowych, sieciach lokalnych lub tam, gdzie nie potrzebujesz zaufania publicznego (bo i tak tylko Ty będziesz ich używać, np. do uwierzytelnienia Ansible).

Czego potrzebujesz: Zainstalowany OpenSSL (dostępny na Linuxie domyślnie, dla Windowsa znajdziesz instalator np. na Win32 OpenSSL).

Pamiętaj: Domyślnie OpenSSL tworzy pliki w katalogu, w którym aktualnie się znajdujesz w wierszu poleceń. Stwórz sobie osobny katalog na swoje certyfikaty, np. `C:\MojeCertyfikaty` na Windowsie, lub `~/certyfikaty` na Linuxie, i pracuj tam.

Krok 1: Wygeneruj Klucz Prywatny (dla Twojej strony/usługi)

To Twój unikalny, tajny klucz. Nikt nie może go poznać.

openssl genrsa -out server.key 2048

Wyjaśnienie: Tworzy nowy klucz prywatny (`server.key`) o długości 2048 bitów. To jak stworzenie własnego, prywatnego klucza do skrzynki pocztowej.

Krok 2: Utwórz Żądanie Podpisania Certyfikatu (CSR)

CSR (Certificate Signing Request) to plik, który zawiera Twoje publiczne dane (np. nazwę strony) i klucz publiczny. Wysyłasz go do Urzędu Certyfikacji, żeby go podpisali.

openssl req -new -key server.key -out server.csr

Podczas tworzenia CSR zostaniesz poproszony o podanie kilku informacji. Ważne jest Common Name (CN), które powinno być nazwą Twojej domeny (np. mojastrona.pl) lub adresem IP (np. 192.168.1.100). Jeśli certyfikat ma być do Ansible, może to być nazwa hosta, np. ansible-host.

Wyjaśnienie: Na podstawie klucza prywatnego (`server.key`) tworzy żądanie podpisania (`server.csr`). To jak wypełnienie wniosku o paszport, z Twoimi danymi i miejscem na pieczęć.

Krok 3: Podpisz Własnoręcznie Certyfikat (Self-Signed)

Jeśli nie masz własnego Urzędu Certyfikacji (CA) i nie chcesz kupować certyfikatu, możesz podpisać swój CSR własnym kluczem prywatnym. Taki certyfikat będzie działał, ale przeglądarki będą na niego narzekać, dopóki nie dodasz go do listy zaufanych.

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Wyjaśnienie: Bierzemy żądanie podpisania (`server.csr`), podpisujemy je naszym własnym kluczem prywatnym (`server.key`), ustawiamy ważność na 365 dni i zapisujemy jako plik certyfikatu (`server.crt`). To jak samodzielne podpisanie swojego wniosku o paszport, bez pieczęci urzędu.

Masz teraz dwa ważne pliki: server.key (klucz prywatny - trzymaj w sekrecie!) i server.crt (certyfikat - możesz go udostępnić).

7. Tworzenie Własnego Urzędu Certyfikacji (CA) i Podpisywanie Certyfikatów

Jeśli chcesz mieć więcej kontroli nad certyfikatami w swojej sieci (np. dla wielu serwerów), możesz stworzyć własne CA. Wtedy Twoje CA będzie "podpisywać" certyfikaty dla innych serwerów/usług, a Ty (i Twoi użytkownicy) będziecie ufać tylko Twojemu CA.

Krok 1: Utwórz Klucz Prywatny dla Twojego CA

To jest główny, tajny klucz Twojego "urzędu".

openssl genrsa -out ca.key 2048

Krok 2: Utwórz Certyfikat dla Twojego CA (Self-Signed CA)

To jest "pieczęć" Twojego urzędu. Musisz go podpisać własnoręcznie, aby stał się samodzielnym CA.

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Podaj informacje dla CA, np. Common Name (CN) jako MojeWewnetrzneCA.

Wyjaśnienie: Tworzymy samopodpisany certyfikat CA (`ca.crt`), ważny 10 lat, używając klucza prywatnego CA (`ca.key`).

Krok 3: Użyj Swojego CA do Podpisania Żądania Certyfikatu (CSR)

Teraz, gdy masz swoje CA, możesz podpisywać nim żądania certyfikatów dla innych serwerów (np. server.csr, który stworzyłeś wcześniej).

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server_signed.crt -days 365

Wyjaśnienie: Podpisujemy żądanie (`server.csr`) za pomocą certyfikatu CA (`ca.crt`) i klucza prywatnego CA (`ca.key`). Wynikowy certyfikat (`server_signed.crt`) będzie zaufany, jeśli system lub przeglądarka ufa Twojemu CA (`ca.crt`).

Gdzie zapisywane są te pliki? Domyślnie w katalogu, z którego uruchamiasz polecenia OpenSSL.

Aby przeglądarka lub system ufały server_signed.crt, musisz dodać ca.crt (certyfikat Twojego CA) do listy zaufanych urzędów w systemie operacyjnym lub przeglądarce (patrz punkt 8).

8. Przykład: Własne Certyfikaty dla Ansible (Uwierzytelnianie)

Ansible często używa SSH do łączenia się z serwerami, ale czasami potrzebujesz certyfikatów do innych celów, np. do zabezpieczania API, serwisu webowego uruchomionego na kontrolerze Ansible, albo do uwierzytelniania wzajemnego (mutual TLS) między komponentami.

Załóżmy, że chcesz zabezpieczyć panel webowy AWX/Ansible Tower lub połączyć się z jakimś API z Ansible, używając certyfikatów, które sam wydałeś.

Krok 1: Przygotuj katalogi i pliki CA

mkdir my_ansible_ca
cd my_ansible_ca
openssl genrsa -out ca_ansible.key 2048
openssl req -new -x509 -days 3650 -key ca_ansible.key -out ca_ansible.crt -subj "/CN=MyAnsibleCA"

Wyjaśnienie: Tworzymy własne CA specjalnie dla Ansible. `ca_ansible.key` to klucz prywatny CA, `ca_ansible.crt` to certyfikat CA. `CN=MyAnsibleCA` to nazwa naszego CA.

Krok 2: Wygeneruj klucz prywatny i CSR dla serwera/usługi Ansible

Załóżmy, że Twój serwer Ansible ma adres IP `192.168.1.50` lub nazwę `ansible.local`.

openssl genrsa -out ansible_server.key 2048
openssl req -new -key ansible_server.key -out ansible_server.csr -subj "/CN=ansible.local"

Jeśli potrzebujesz wielu nazw domen/IP w jednym certyfikacie (np. `ansible.local` i `192.168.1.50`), musisz użyć pliku konfiguracyjnego dla OpenSSL (np. `extfile.cnf`):

# extfile.cnf
[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName_default = PL
stateOrProvinceName_default = Mazowieckie
localityName_default = Warszawa
organizationName_default = Moja Firma
organizationalUnitName_default = IT
commonName_default = ansible.local
[ v3_req ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = ansible.local
IP.1 = 192.168.1.50

A następnie użyj go do wygenerowania CSR:

openssl req -new -key ansible_server.key -out ansible_server_multi.csr -config extfile.cnf

Krok 3: Podpisz CSR za pomocą Twojego Ansible CA

openssl x509 -req -days 730 -in ansible_server.csr -CA ca_ansible.crt -CAkey ca_ansible.key -CAcreateserial -out ansible_server.crt

Lub dla wersji z wieloma nazwami:

openssl x509 -req -days 730 -in ansible_server_multi.csr -CA ca_ansible.crt -CAkey ca_ansible.key -CAcreateserial -out ansible_server_multi.crt -extensions v3_req -extfile extfile.cnf

Wynik: Masz teraz pliki ansible_server.key (klucz prywatny serwera Ansible) i ansible_server.crt (certyfikat serwera Ansible podpisany przez Twoje CA). Te pliki, podobnie jak poprzednie, zostaną utworzone w katalogu, w którym wykonujesz polecenia OpenSSL.

Krok 4: Skonfiguruj usługę/Ansible do używania certyfikatów

Dla serwera WWW/API (np. Nginx lub Apache hostujący jakiś panel Ansible):

Musisz wskazać ścieżki do `ansible_server.key` i `ansible_server.crt` w konfiguracji serwera webowego (np. w pliku `nginx.conf` lub `httpd.conf`):

# Przykład konfiguracji Nginx
server {
    listen 443 ssl;
    server_name ansible.local 192.168.1.50;

    ssl_certificate /path/to/your/ansible_server.crt; # Tutaj wstaw ścieżkę do pliku .crt
    ssl_certificate_key /path/to/your/ansible_server.key; # Tutaj wstaw ścieżkę do pliku .key

    # Opcjonalnie, jeśli klienci też mają się uwierzytelniać certyfikatem
    # ssl_client_certificate /path/to/your/ca_ansible.crt;
    # ssl_verify_client on;

    location / {
        # ... konfiguracja Twojej aplikacji ...
    }
}

Pamiętaj, aby pliki `.crt` i `.key` były dostępne dla serwera webowego i miały odpowiednie uprawnienia! Zazwyczaj umieszcza się je w bezpiecznych katalogach, np. `/etc/ssl/certs/` i `/etc/ssl/private/` na Linuxie, lub w dedykowanych katalogach w Windows Server.

Dla klienta (np. przeglądarki lub skryptu Ansible łączącego się z API):

Aby przeglądarka lub aplikacja kliencka ufała certyfikatowi `ansible_server.crt`, musisz zaimportować `ca_ansible.crt` (certyfikat Twojego CA) do magazynu zaufanych certyfikatów w systemie operacyjnym klienta.

  • Windows: Kliknij prawym przyciskiem myszy na `ca_ansible.crt` -> "Zainstaluj certyfikat" -> Wybierz "Lokalny komputer" -> "Umieść wszystkie certyfikaty w następującym magazynie" -> "Zaufane główne urzędy certyfikacji".
    Gdzie to się zapisze? W magazynie certyfikatów Windows. Możesz to sprawdzić, wpisując `certmgr.msc` w polu wyszukiwania Windowsa (lub w Uruchom - Win+R). Zobaczysz tam "Zaufane główne urzędy certyfikacji".
  • Linux: Skopiuj `ca_ansible.crt` do `/usr/local/share/ca-certificates/` (lub `/etc/pki/ca-trust/source/anchors/` na nowszych dystrybucjach Red Hat/CentOS) i uruchom `sudo update-ca-certificates` (dla Debian/Ubuntu) lub `sudo update-ca-trust extract` (dla Red Hat/CentOS).
    Gdzie to się zapisze? Systemy Linux mają różne miejsca, ale zazwyczaj po aktualizacji są one dostępne w `/etc/ssl/certs/` lub podobnych katalogach.

Teraz, gdy będziesz łączyć się z `ansible.local` (lub `192.168.1.50`) za pomocą HTTPS, przeglądarka nie powinna pokazywać ostrzeżenia o niezaufanym połączeniu, ponieważ ufa CA, które podpisało certyfikat.

Użycie w zadaniach Ansible (moduł `uri` do połączeń HTTPS):

Jeśli Twoje zadanie Ansible łączy się z usługą HTTPS, która używa certyfikatu podpisanego przez Twoje wewnętrzne CA, możesz określić ścieżkę do certyfikatu CA:

# Przykład taska Ansible
- name: Pobierz dane z wewnętrznego API
  uri:
    url: https://ansible.local/api/status
    method: GET
    validate_certs: yes
    # Ścieżka do Twojego certyfikatu CA, aby Ansible mu zaufał
    ca_path: /path/to/your/ca_ansible.crt # Tutaj wstaw ścieżkę do pliku ca_ansible.crt
  register: api_response

Wyjaśnienie: Parametr `ca_path` mówi Ansible, gdzie znaleźć certyfikat CA, któremu powinien ufać podczas weryfikacji certyfikatu serwera API. Dzięki temu nie dostaniesz błędu o niezaufanym certyfikacie.

Brak komentarzy:

Prześlij komentarz