Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


26.05.2020

Cloud Native Universe

Jako patron medialny zapraszamy programistów wdrażających lub integrujących się z dowolną...
26.03.2020

Koniec certyfikatów...

MCSA, MCSD i MCSA
26.03.2020

Odświeżony OS

FortiOS 6.4
26.03.2020

Bezpieczeństwo w chmurze

Cisco SecureX
26.03.2020

Modernizacja IT

Nowości w VMware Tanzu
26.03.2020

Krytyczne zagrożenie dla...

Nowa groźna podatność
26.03.2020

Laptopy dla wymagających

Nowe ThinkPady T, X i L
26.03.2020

Serwerowe ARM-y

Ampere Altra
26.03.2020

Energooszczędny monitor

Philips 243B1

Openssl – zarządzanie wielopoziomowym PKI

Data publikacji: 22-01-2020 Autor: Grzegorz Kuczyński
W poprzedniej części naszego cyklu utworzyliśmy proste PKI dla serwerów WWW. Dziś zaprezentujemy, jak stworzyć wielopoziomowy PKI w OpenSSL oraz jak nim zarządzać. Rozszerzymy go również o listy CRL i certyfikaty dla klientów.
 
Testowe PKI nazwiemy AuthLab – będzie to nazwa organizacji. Główne centrum certyfikacji (CA) nazwiemy RootCA i podpiszemy nim dwa podcentra CA. Pierwsze z nich SubWebCA będzie służyło do wystawiania certyfikatów dla serwerów WWW – w naszym przypadku będzie to Apache. Drugi z urzędów certyfikacji – SubWebClientCA będzie wystawiał dla klientów serwerów webowych certyfikaty, które będą używane w przeglądarkach WWW. Oba wspomniane pod CA (SubWebCA i SubWebClientCA) będą autoryzowane przez RootCA i w każdej chwili będą mogły zostać przez niego odwołane poprzez listy CRL (Certificate Revocation List – listy certyfikatów unieważnionych). Ponadto każde z podcentrów certyfikacji będzie mogło również odwołać dowolny wydany przez siebie certyfikat poprzez swoje listy CRL.
 
> GŁÓWNE CENTRUM RootCA
 
Główne CA naszego PKI będzie bazowało w znacznej mierze na konfiguracji, którą przedstawiliśmy w poprzedniej części cyklu („IT Professional” 1/2020, s. 48). W pierwszej kolejności musimy stworzyć strukturę katalogów i niezbędne pliki. Nowością w stosunku do zagadnień opisanych w ubiegłym miesiącu są katalog i pliki dla CRL.
 
 
 
 
Poniżej przedstawiamy plik konfiguracyjny głównego CA, gdzie zostały zaprezentowane tylko te opcje, które uległy zmianie w stosunku do CA prezentowanego w poprzedniej części:
 
# cat MyCA/RootCA/RootCA.cnf
...
[ CA_default ]
dir = ./MyCA/RootCA
...
certificate = $dir/rootCA.crt.pem
private_key = $dir/private/rootCA.key.pem
x509_extensions = sub_ca
...
crl_dir = $dir/crl
crlnumber = $dir/crlnumber
crl = $dir/crl.pem
default_crl_days= 30
...
[ root_ca ]
keyUsage = critical,keyCertSign,cRLSign
basicConstraints = critical,CA:true,pathlen:1
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
[ sub_ca ]
keyUsage = critical,keyCertSign,cRLSign
basicConstraints = critical,CA:true,pathlen:0
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
 
Zmiany dotyczą głównie położenia certyfikatu i klucza prywatnego, opcji dotyczących list CRL oraz sekcji rozszerzeń. Domyślnymi rozszerzeniami są sub_ca; określają one pod CA, które będziemy podpisywać. Ich długość ścieżki wynosi 0, czyli będą ostatnimi CA na ścieżce walidacji. Z kolei root_ca określa parametry głównego CA (self-signed) i jego ścieżka wynosi 1. Warto zastanowić się również nad okresem ważności dla listy CRL, w naszym przypadku ustawionej na 30 dni. Jednak w rzeczywistości tak częste generowanie list CRL wynikające wyłącznie z upływającego okresu ważności może być dość uciążliwe. 
Czas na wygenerowanie klucza prywatnego i zapytania CSR:
 
# openssl req -new -nodes
-config MyCA/RootCA/RootCA.cnf
-out MyCA/RootCA/req/rootCA.csr.pem
-keyout MyCA/RootCA/private/rootCA.key.pem
-subj "/CN=RootCA/O=AuthLab"
# openssl req -in MyCA/RootCA/req/rootCA.csr.pem -noout -text
 
Podpisując to zapytanie, nie korzystamy jednak z domyślnych rozszerzeń sub_ca, tylko wskazujemy za pomocą opcji rozszerzenie przeznaczone dla RootCA. W tym momencie należy również zdecydować o terminie ważności naszego certyfikatu i o zależnościach z tego wynikających (zagadnienia również opisane w poprzedniej części cyklu):
 
# openssl ca -selfsign
-config MyCA/RootCA/RootCA.cnf
-in MyCA/RootCA/req/rootCA.csr.pem
-out MyCA/RootCA/rootCA.crt.pem
-extensions root_ca
-days 1460
-create_serial
-batch
# openssl x509 -in MyCA/RootCA/rootCA.crt.pem -text -noout
# openssl verify -CAfile MyCA/RootCA/rootCA.crt.pem
MyCA/RootCA/rootCA.crt.pem
 
Wynikiem powyższych działań są dwa z najważniejszych plików. Pierwszym jest certyfikat rootCA.crt.pem, który będziemy wykorzystywać w konfiguracji zarówno serwera, jak i klienta. Drugim jest jego prywatny klucz rootCA.key.pem, który powinien być najbardziej chronionym plikiem w naszym PKI.
 
> CENTRUM SubWebCA
 
Kolejne CA będzie wystawiać certyfikaty dla serwerów TLS. Analogicznie tworzymy strukturę katalogów:
 
 
Plik konfiguracyjny SubWebCA będzie różnił się od RootCA tylko poniższymi opcjami. Oczywiście wymieniamy w nim całkowicie sekcje rozszerzeń X.509v3:
 
# cat MyCA/SubWebCA/SubWebCA.cnf
...
[ CA_default ]
dir = ./MyCA/SubWebCA
...
certificate = $dir/subWebCA.crt.pem
private_key = $dir/private/subWebCA.key.pem
x509_extensions = srv_cert
...
[ srv_cert ]
basicConstraints = critical,CA:FALSE
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = *.ctl.lab
DNS.2 = *.test.lab
 
Nowością jest tu sposób przypisania wielu subdomen do rozszerzenia subjectAltName.
Tak samo jak poprzednio kolejnym krokiem jest wygenerowanie zapytania i klucza prywatnego:
 
 
Pora na bardzo istotny moment – podpisanie certyfikatu SubWebCA przez RootCA. Ponieważ oba CA są zlokalizowane w tej samej maszynie, nie musimy kopiować pliku zapytania CSR na maszynę, gdzie jest RootCA, a po podpisaniu z powrotem kopiować podpisany certyfikat CRT:
 
 
Jak widać, korzystamy tu z domyślnych rozszerzeń, a weryfikację przeprowadzamy przy użyciu certyfikatu RootCA. Tu również należy rozważyć termin ważności CA.
 
> CENTRUM SubWebClientCA
 
Ostatnie CA przeznaczone jest dla klientów, którym będą wydawane certyfikaty:
 
 
Tu również kopiujemy konfigurację z poprzednio tworzonego CA i zmieniamy tylko poniżej wskazane opcje:
 
# cat MyCA/SubWebClientCA/SubWebClientCA.cnf
...
[ CA_default ]
dir = ./MyCA/SubWebClientCA
...
certificate = $dir/subWebClientCA.crt.pem
private_key = $dir/private/subWebClientCA.key.pem
x509_extensions = client_cert
...
[ client_cert ]
basicConstraints = critical,CA:FALSE
keyUsage = critical,digitalSignature
extendedKeyUsage = clientAuth
 
Następnie tworzymy zapytanie:
 
 
[...]
 
Autor zawodowo zajmuje się informatyką. Jest członkiem społeczności open source, prowadzi blog nt. systemu GNU/Linux. 

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"