infrastruktura klucza...
TRANSCRIPT
01.10.2019
Strona 1 z 9
Infrastruktura Klucza Publicznego
W laboratorium zostanie wykorzystane środowisko OpenSSL. Jest to zestaw narzędzi
kryptograficznych, pozwalających na wykorzystywanie m.in. popularnych algorytmów kryptografii
symetrycznej i asymetrycznej, funkcji skrótów i certyfikatów. Środowisko składa się z modułów,
odpowiedzialnych za obsługę poszczególnych technologii. W zadaniu zostaną wykorzystane głównie
moduły genrsa (do generowania kluczy RSA), rsa (do zarządzania kluczami) oraz req (do składania
wniosków o podpisanie certyfikatu, tzw. CSR – Certificate Signing Request).
Użytkowanie odbywa się w trybie interaktywnym (po wpisaniu polecenia openssl w terminalu) lub
skryptowym: openssl MODUŁ PARAMETRY_MODUŁU
W zadaniu wykorzystamy możliwość tworzenia infrastruktury klucza publicznego (PKI – Public Key
Infrastructure). Utworzona zostanie najprostsza możliwa architektura PKI – główny urząd certyfikacji
(Root CA) oraz jeden podległy mu urząd podpisujący (Signing CA):
Rys.1. Architektura PKI z zadania (źródło tego i następnych obrazków: pki-tutorial.readthedocs.io).
Należy mieć świadomość, że w rzeczywistym stosowaniu PKI architektura jest zazwyczaj
dwuwarstwowa z wydzielonymi Intermediate CA, osobnymi dla usług różnych typów lub
trójwarstwowa z dodatkowym podziałem zależnym od funkcji certyfikatów w danej usłudze (np.
osobne CA do wystawiania certyfikatów dla użytkowników w sieci oraz osobne dla usług w tej samej
sieci):
01.10.2019
Strona 2 z 9
Rys. 2. Typowa dwuwarstwowa architektura PKI.
Rys. 3. Typowa trójwarstwowa architektura PKI.
01.10.2019
Strona 3 z 9
Formaty zapisu certyfikatów:
DER - Distinguished Encoding Rules – binarny plik, często wykorzystywany w systemach Windows
(domyślny format eksportu kluczy i certyfikatów w Windows)
PEM - Privacy Enhanced Mail – certyfikat lub klucz, pierwotnie w formacie DER, zakodowany
w Base64, popularny w systemach Linux i większości oprogramowania (Apache mod_ssl, stunnel itd.)
P12 – PKCS #12 – format przechowywania pary kluczy (publicznego i prywatnego) w stanie
zaszyfrowanym, zabezpieczonych hasłem. Rozwinięty przez Microsoft i tam najczęściej spotykany,
opisany w RFC 7292.
Często spotykane są także rozszerzenia plików:
.key – klucz prywatny
.pub – klucz publiczny
.crt – certyfikat, często wykorzystywane rozszerzenie w Windows jako synonim do .pem
Instrukcja do ćwiczenia:
Główny urząd certyfikacji (Root CA) jest źródłem zaufania. Inne urządzenia w sieci ufają posiadaczom
certyfikatów podpisanych przez Root CA bezpośrednio (raczej rzadko spotykane rozwiązanie) lub
pośrednio, poprzez pośrednie urzędy certyfikacji (Intermediate CA), których zadaniem jest
wystawianie certyfikatów końcowym użytkownikom lub usługom.
Klucze prywatne powinny być dobrze chronione. Skompromitowanie klucza prywatnego prowadzi do
równoczesnego skompromitowania dokumentów podpisanych z jego pomocą – nie da się określić,
czy podpisy zostały wystawione przez prawowitego właściciela klucza. Szczególnie dobrze powinny
być chronione klucze urzędów certyfikacji. Dlatego też Root CA wykorzystuje się tylko do
podpisywania kluczy urzędów pośrednich – sam klucz Root CA przechowywany powinien być
w bezpiecznym środowisku, jak moduł HSM lub odizolowane od sieci urządzenie, wykorzystywane
tylko jako przestrzeń dla CA.
W przypadku skompromitowania CA skompromitowane zostają również wszystkie certyfikaty przez
niego wystawione, także pośrednio (nie jest problemem utworzyć pośrednie CA, korzystając ze
skradzionego klucza).
1. Utworzenie Root CA
Należy rozpocząć od utworzenia miejsca (katalogu) przechowywania plików składających się na Root
CA. Wykorzystany zostanie w tym celu katalog /root/ca:
# mkdir /root/ca
W stworzonym katalogu musi zostać utworzona struktura urzędu. Podkatalogi służą do
przechowywania wydanych certyfikatów (certs), nowych certyfikatów (newcerts), przechowywania
informacji o unieważnionych certyfikatach (crl) oraz klucza prywatnego CA (private). Podane nazwy
są przykładowe, jednak muszą zostać umieszczone w pliku konfiguracyjnym OpenSSL. Plik index.txt
jest wykorzystywany jako baza danych o podpisanych certyfikatach, a serial jest numerem
porządkowym ostatnio wydanego certyfikatu.
01.10.2019
Strona 4 z 9
# cd /root/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
Następnym krokiem jest stworzenie pliku konfiguracyjnego OpenSSL dla urzędu certyfikacji.
Przykładowy plik dostępny jest pod adresem https://jamielinux.com/docs/openssl-certificate-
authority/appendix/root-configuration-file.html (bezpośredni link do pliku:
https://jamielinux.com/docs/openssl-certificate-authority/_downloads/root-config.txt lub skrócony:
http://urwij.net/1804/) i zostanie on przez nas użyty w dalszej części instrukcji. Nazwę pliku należy
zmienić na openssl.cnf lub w dalszej części instrukcji odpowiednio wykorzystywać aktualną nazwę.
Obowiązkowa sekcja [ ca ] zawiera wskazanie na stosowaną sekcję konfiguracji (może być ich więcej).
W sekcji [ default_ca ] odpowiedzialnej za konfigurację urzędu certyfikacji, wskazywana jest polityka
wystawiania certyfikatów. Określa ona, między innymi, jakie atrybuty muszą być w nich zawarte
i jakie wartości są dozwolone. W przypadku urzędu Root CA, przyjętą w przykładzie polityką jest
policy_strict, zostanie ona wykorzystana tylko dla certyfikatów wystawianych przez Root CA, a więc
tylko certyfikatów urzędów pośrednich. Certyfikaty końcowe (dla usług i użytkowników) wystawiane
będą z użyciem polityki policy_loose.
Za obsługę wniosków o podpisanie kluczy odpowiada sekcja [ req ] i wskazywane przez nią następne
sekcje. Dodatkowe atrybuty zawarte w certyfikatach, opisywane standardem X.509v3, obsługuje
sekcja [ v3_ca ].
Pozostałe sekcje omówione zostaną później.
Następnym krokiem jest utworzenie pary kluczy Root CA. Klucz musi być przechowywany
w bezpiecznym miejscu i mieć możliwie dużą długość – klucz prywatny Root CA wykorzystywany jest
rzadko i niska wydajność związana z długością klucza nie jest problemem. Dużo ważniejsze jest, by
klucz nie został skompromitowany.
Plik z kluczem szyfrowany jest z wykorzystaniem algorytmu symetrycznego, pozwalającego na
przechowywanie go w ukrytej formie, zabezpieczonej podanym hasłem. Hasła, ani klucza
prywatnego, nie należy udostępniać.
# cd /root/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096
Enter pass phrase for ca.key.pem: SECRETPASSWORD
Verifying - Enter pass phrase for ca.key.pem: SECRETPASSWORD
# chmod 400 private/ca.key.pem
Dla stworzonego klucza prywatnego należy wygenerować samopodpisany certyfikat.
# cd /root/ca
# openssl req -config openssl.cnf \
-key private/ca.key.pem \
-new -x509 -days 7300 -sha256 -extensions v3_ca \
-out certs/ca.cert.pem
01.10.2019
Strona 5 z 9
Enter pass phrase for ca.key.pem: SECRETPASSWORD
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:PL
State or Province Name []:Malopolska
Locality Name []:
Organization Name []:MOJA NIEWIELKA FIRMA SP ZOO
Organizational Unit Name []:CA MOJEJ NIEWIELKIEJ FIRMY
Common Name []:MNF Root CA
Email Address []:
# chmod 444 certs/ca.cert.pem
Stworzony certyfikat można zweryfikować:
# openssl x509 -noout -text -in certs/ca.cert.pem
2. Utworzenie Intermediate CA
Dla pośredniego CA należy utworzyć osobny katalog i stworzyć w nim odpowiednią strukturę:
# mkdir /root/ca/intermediate
# cd /root/ca/intermediate
# mkdir certs crl csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
Tworzymy także numer seryjny dla listy unieważnianych certyfikatów (CRL – Certificate Revocation
List):
# echo 1000 > /root/ca/intermediate/crlnumber
Kopiujemy konfigurację OpenSSL z Root CA:
# cp /root/ca/openssl.cnf /root/ca/intermediate/openssl.cnf
W konfiguracji należy poprawić zmienne odnoszące się do położenia odpowiednich plików i
katalogów, a także wskazać politykę odpowiednią dla pośredniczącego CA, służącego do
podpisywania certyfikatów dla użytkowników końcowych:
[ CA_default ]
dir = /root/ca/intermediate
private_key = $dir/private/intermediate.key.pem
certificate = $dir/certs/intermediate.cert.pem
crl = $dir/crl/intermediate.crl.pem
policy = policy_loose
Należy także utworzyć parę kluczy dla pośredniczącego CA. Klucza tego nie należy nikomu ujawniać,
ponieważ jego skompromitowanie będzie prowadzić do możliwości wystawiania certyfikatów przez
kogoś, kto przechwyci klucz prywatny.
# cd /root/ca
# openssl genrsa -aes256 \
-out intermediate/private/intermediate.key.pem 4096
Enter pass phrase for intermediate.key.pem: SECRETPASSWORD
01.10.2019
Strona 6 z 9
Verifying - Enter pass phrase for intermediate.key.pem: SECRETPASSWORD
# chmod 400 intermediate/private/intermediate.key.pem
Po stworzeniu klucza prywatnego należy wystąpić o jego podpisanie do Root CA. Służy do tego tzw.
CSR. Dane wprowadzane we wniosku o podpisanie certyfikatu powinny zgadzać się z danymi
podanymi przy podpisywaniu Root CA, z wyjątkiem opcji „Common Name”, która nie może być taka
sama i powinna identyfikować pośredniczące CA.
Podczas tworzenia CSR należy wskazać plik konfiguracji OpenSSL właściwy dla Intermediate CA.
# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
-key intermediate/private/intermediate.key.pem \
-out intermediate/csr/intermediate.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:PL
State or Province Name []:Malopolska
Locality Name []:
Organization Name []:MOJA NIEWIELKA FIRMA SP ZOO
Organizational Unit Name []:CA MOJEJ NIEWIELKIEJ FIRMY
Common Name []:MNF Intermediate CA
Email Address []:
Podpisujemy certyfikat Intermediate CA z użyciem klucza prywatnego Root CA (należy podać hasło
zabezpieczające klucz):
# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
-days 3650 -notext -md sha256 \
-in intermediate/csr/intermediate.csr.pem \
-out intermediate/certs/intermediate.cert.pem
Ustawiamy w następnej kolejności odpowiednie uprawnienia do pliku z certyfikatem serwera
pośredniczącego:
# chmod 444 intermediate/certs/intermediate.cert.pem
Informacja o podpisaniu certyfikatu powinna pojawić się w bazie operacji Root CA, w pliku index.txt.
Wystawiony certyfikat dla Intermediate CA można zweryfikować, wyświetlając jego parametry:
# openssl x509 -noout -text \
-in intermediate/certs/intermediate.cert.pem
Można zweryfikować go także z użyciem certyfikatu Root CA:
# openssl verify -CAfile certs/ca.cert.pem \
intermediate/certs/intermediate.cert.pem
intermediate.cert.pem: OK.
01.10.2019
Strona 7 z 9
Użytkownik, który chce upewnić się, że usługa, z której chce skorzystać, została potwierdzona przez
zaufany przez niego urząd certyfikacji (źródło zaufania), musi mieć możliwość otworzenia tzw.
„łańcucha zaufania”. Są to certyfikaty głównego CA oraz wszystkich pośredniczących CA pomiędzy
Root CA a końcową usługą, lub użytkownikiem, którego chcemy uwierzytelnić.
Łańcuch zaufania realizuje się poprzez dostarczenie pliku ze wszystkimi certyfikatami (od Root CA
włącznie) lub pliku ze wszystkimi certyfikatami z łańcucha, poza Root CA. Certyfikat Root CA
zazwyczaj dostarczany jest osobno i wymagane jest, by był on w systemie użytkownika uznany za
zaufany, ponieważ jest on certyfikatem samopodpisanym i nie ma innej możliwości jego weryfikacji.
W przypadku infrastruktury PKI z zadania łańcuch zaufania składa się z dwóch certyfikatów: Root CA
oraz Intermediate CA. Tworzy się go poprzez zapisanie do pliku tych dwóch certyfikatów:
# cat intermediate/certs/intermediate.cert.pem \
certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
Dodatkowo, można nadać odpowiednie uprawnienia dostępu do pliku, zmniejszając możliwość jego
nieumyślnej modyfikacji:
# chmod 444 intermediate/certs/ca-chain.cert.pem
3. Utworzenie certyfikatu użytkownika końcowego
Dla użytkownika końcowego należy utworzyć parę kluczy, a następnie wniosek o podpisanie (CSR).
W przykładzie działanie to wykonywane jest już w urzędzie certyfikacji, jednak często – jeżeli
użytkownik nie chce ujawniać swojego klucza prywatnego – samodzielnie generuje CSR i wysyła do
podpisania przez CA. Funkcję pośredniczącą może pełnić także wydzielony urząd rejestracji (RA –
Registration Authority).
Należy utworzyć parę kluczy dla użytkownika. Klucz może mieć długość 2048, co spowoduje większą
wydajność szyfrowania takim kluczem. Ponieważ nie jest on krytyczny, a zazwyczaj podpis
wystawiany jest na około rok, taka długość klucza jest dopuszczalna. Opcję –aes256 można pominąć,
jeśli klucz ma pozostać niezaszyfrowany (w przypadku szyfrowania, każdorazowe użycie klucza,
wymaga podania hasła do niego, np. przy restarcie serwera HTTPS lub szyfrowaniu wiadomości e-
mail).
# cd /root/ca
# openssl genrsa -aes256 \
-out intermediate/private/www.example.com.key.pem 2048
# chmod 400 intermediate/private/www.example.com.key.pem
Dla utworzonego klucza należy wygenerować CSR:
# cd /root/ca
# openssl req -config intermediate/openssl.cnf \
-key intermediate/private/www.example.com.key.pem \
-new -sha256 -out intermediate/csr/www.example.com.csr.pem
Enter pass phrase for www.example.com.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:PL
01.10.2019
Strona 8 z 9
State or Province Name []:Malopolska
Locality Name []:Krakow
Organization Name []:INNA NIEWIELKA FIRMA
Organizational Unit Name []:WWW INNEJ NIEWIELKIEJ FIRMY
Common Name []:www.example.com
Email Address []:
Wniosek CSR podpisujemy kluczem Intermediate CA:
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-extensions server_cert -days 375 -notext -md sha256 \
-in intermediate/csr/www.example.com.csr.pem \
-out intermediate/certs/www.example.com.cert.pem
# chmod 444 intermediate/certs/www.example.com.cert.pem
Poprawność klucza można zweryfikować, wyświetlając jego parametry:
# openssl x509 -noout -text \
-in intermediate/certs/www.example.com.cert.pem
…oraz weryfikując „łańcuch zaufania”:
# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
intermediate/certs/www.example.com.cert.pem
Wygenerowany certyfikat można użyć np. w szyfrowaniu lub uwierzytelnianiu poczty elektronicznej,
stron WWW dostępnych po HTTPS itd.
4. Konfiguracja certyfikatu serwera HTTPS
Następnym krokiem będzie instalacja i konfiguracja serwera HTTPS z przykładową stroną,
zabezpieczoną certyfikatem.
Należy zainstalować serwer Apache 2:
# apt-get –y install apache2
Uruchomić moduł SSL w Apache:
# a2enmod ssl
Następnym krokiem jest konfiguracja serwera: W pliku /etc/apache2/sites-available/default-ssl.conf
należy wskazać klucz serwera, certyfikat serwera oraz obsługiwane domeny (pogrubione elementy
powinny zostać ustawione zgodnie z dotychczasową konfiguracją):
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin [email protected]
ServerName www.example.com
ServerAlias example.com
(…)
SSLEngine on
SSLCertificateFile /root/ca/intermediate/certs/www.example.com.cert.pem
SSLCertificateKeyFile /root/ca/intermediate/private/www.example.com.key.pem
(…)
</VirtualHost>
</IfModule>
01.10.2019
Strona 9 z 9
Po skonfigurowaniu, należy włączyć SSL dla hostowanej strony WWW oraz zrestartować serwer
Apache 2:
# a2ensite default-ssl.conf
# service apache2 stop
# service apache2 start
Nie należy stosować polecenia service apache2 restart, ponieważ w trakcie jego wykonywania
użytkownik nie zostanie zapytany o klucz szyfrowania klucza prywatnego i serwer nie uruchomi się
poprawnie.
Domenę www.example.com należy powiązać z adresem hosta lokalnego, inaczej nie zostanie on
rozwiązany na właściwy adres IP. Jest to konieczne, ponieważ certyfikat wystawiony został dla
konkretnej domeny, a nie adresu IP.
W pliku /etc/hosts należy dopisać linię:
127.0.0.1 www.example.com
Po wejściu na stronę https://www.example.com z wybranej przeglądarki internetowej, ukaże się
komunikat o niezaufanym certyfikacie. Łańcuch certyfikatów musi zostać dodany do magazynu
certyfikatów przeglądarki. W przypadku Mozilli Firefox jest to Preferences -> Advanced ->
Certificates -> View Certificates -> Authorities -> Import.
5. Źródła i materiały dodatkowe:
https://jamielinux.com/docs/openssl-certificate-authority/
https://pki-tutorial.readthedocs.io/en/latest/
https://www.phildev.net/ssl/opensslconf.html