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

Zastosowania poleceń OpenSSL – Tworzenie centrum autoryzacji

Data publikacji: 20-12-2019 Autor: Grzegorz Kuczyński
Rys. 1. X.509V3 – standardowe...

W poprzedniej części naszego cyklu poruszyliśmy temat certyfikatów SSL. Jedną z ciekawszych funkcji, jaką oferuje nam OpenSSL w tym zakresie, jest możliwość stworzenia prostego centrum autoryzacji.

 

Stworzenie własnej infrastruktury klucza publicznego (Public Key Infrastructure, PKI) nie jest rzeczą prostą, chociażby ze względu na ogromną odpowiedzialność, jaka się z nią wiąże. Zadaniem urzędu certyfikacyjnego (Certification Authority, CA), jest poręczenie, że dany klucz publiczny należy do konkretnej osoby bądź podmiotu. Ze strony klienta sygnatura CA znajdująca się w certyfikacie serwera lub klienta jest gwarancją autentyczności tego certyfikatu. Chociaż sami twórcy OpenSSL nie zalecają jego użycia do tworzenia profesjonalnego PKI, to na jego bazie powstają takie projekty jak choćby OpenXPKI. OpenSSL natomiast doskonale nadaje się do celów edukacyjnych – to świetny sposób, żeby w praktyce dowiedzieć się, jak działa CA, oraz stworzyć prywatne CA, które będzie używane w sieci wewnętrznej. Jeżeli chcemy wystawiać certyfikaty np. dla naszych wewnętrznych serwerów HTTPS bądź klientów OpenVPN, to OpenSSL jest rozwiązaniem, które się do tego nada. Narzędzie openssl oferuje niemal wszystko, co z technicznego punktu widzenia jest potrzebne do stworzenia CA. Jednak warto pamiętać, że infrastruktura klucza publicznego to coś więcej niż samo generowanie certyfikatów.

 

> ROZSZERZENIA CERTYFIKATÓW

 

Urząd certyfikacyjny CA w OpenSSL tworzymy za pomocą polecenia ca. W przeciwieństwie do innych poleceń to polecenie wymaga odpowiednio skonfigurowanego pliku z mnóstwem opcji. Jednymi z ważniejszych są rozszerzenia certyfikatów. Jeżeli nie dowiemy się, co dokładnie one oznaczają, możemy utracić kontrolę nad wydanymi certyfikatami. Za pomocą licznych rozszerzeń X.509v3 zdefiniowanych w RFC 5280 aplikacje wykorzystujące certyfikaty mogą weryfikować, czy dany certyfikat jest przetwarzany zgodnie z jego przeznaczeniem. Gdyby nie rozszerzenia, mogłoby dojść do sytuacji, w której wystawiony certyfikat mógłby samodzielnie i bez naszej wiedzy wystawiać kolejne certyfikaty, pozytywnie weryfikowane przez nasz certyfikat CA. Główną funkcją rozszerzeń jest określanie, do jakich celów dany certyfikat może być wykorzystany. Używając rozszerzeń, nie tylko możemy zabezpieczyć się przed samozwańczymi pośrednikami naszego CA, ale również kontrolować ich liczbę.

 

> IDENTYFIKATOR WYDAWCY I PODMIOTU

 

Rozszerzenia certyfikatu Subject Key Identifier (SKID, SubjectKeyIdentifier) i Authority Key Identifier (AKID, AuthorityKeyIdentifier) zostały dodane do standardu X.509v3 i pozwalają wystawiać więcej niż jeden certyfikat o tej samej nazwie. Nazwy w formacie DN (Distinguished Names) używane są powszechnie w usługach katalogowych, a poszczególne certyfikaty można odróżnić po wartościach SubjectKeyIdentifier lub AuthorityKeyIdentifier. Dzięki temu możliwe jest ponowne użycie tej samej nazwy wydawcy lub podmiotu w wydawanym certyfikacie. W takiej sytuacji nasuwa się jednak pytanie, jaki jest sens wydawania dwóch certyfikatów dla tego samego podmiotu? Otóż w przypadku publicznych CA jeden klient może wystąpić do więcej niż jednego CA o certyfikat z taką samą nazwą, dzięki czemu gdy jeden z wystawców nie będzie honorowany w danym środowisku, uznawany będzie kolejny. Z drugiej strony posiadanie wielu certyfikatów przez CA ma na celu zapewnienie ciągłości w procesie weryfikacji wydanych certyfikatów. Każdy certyfikat CA jest ważny terminowo, gdyż z biegiem lat jego klucz może okazać się za krótki. Załóżmy, że certyfikat CA jest ważny przez cztery lata, a certyfikaty wydawane dla klientów będą ważne przez dwa lata. Aby certyfikaty klientów ciągle mogły być weryfikowane poprawnie przez CA, po upływie dwóch lat należy wygenerować nowy certyfikat dla CA i tylko jego używać do podpisywania kolejnych klientów. Innymi słowy, po dwóch latach od wygenerowania pierwszego klucza dla CA w obiegu będą dwa certyfikaty CA z taką samą nazwą.

 

> PODSTAWOWE OGRANICZENIA

 

Zadaniem rozszerzenia basicConstraints jest kontrola certyfikatów głównego CA oraz jego pośredników, czyli Intermediate CA. W tym rozszerzeniu certyfikat CA musi mieć ustawioną opcję cA na wartość TRUE, natomiast certyfikaty niepełniące roli CA muszą mieć ustawioną opcję cA na FALSE. Ponadto za pomocą opcji pathLenConstraint można określać maksymalną liczbę pośredników. Jeżeli nie określimy tej wartości, certyfikat CA będzie akceptował dowolną liczbę pośrednich CA w łańcuchu weryfikacji (rys. 2).


Planując stworzenie własnego CA, musimy wziąć pod uwagę okres ważności wydawanych certyfikatów. Przykład pokazany na rys. 3 ilustruje, w jaki sposób możliwe jest zapewnienie ciągłości walidacji dla certyfikatów końcowych przez klucz CA. W momencie A generowany jest klucz dla CA. Po pewnym czasie tworzymy pośrednie CA, które następnie podpisuje certyfikat końcowy User A. Ścieżka walidacji tego certyfikatu oznaczona jest na niebiesko. W momencie B generujemy nowy klucz naszego CA, a następnie generujemy również nowy klucz dla pośredniego CA i podpisujemy go nowym kluczem głównego CA. W momencie C kończy się ważność certyfikatu User A, więc wydajemy nowy, podpisując go już nowym kluczem pośredniego CA – zielona ścieżka walidacji. W momencie D pierwszy klucz pośredniego CA traci swoją ważność i podpisane nim klucze nie mogą już być poprawnie weryfikowane.

 

> WYKORZYSTANIE KLUCZA


Innym istotnym rozszerzeniem jest keyUsage oferujące szereg wartości, które określają, do jakich celów może zostać użyty publiczny klucz zawarty w certyfikacie. Spośród dostępnych wartości warto wymienić:

 

  • keyCertSign – zezwala na weryfikację sygnatury certyfikatu, właściciel klucza prywatnego uprawniony jest do podpisywania certyfikatów (rola CA).
  • cRLSign – zezwala na podpisywanie listy CRL (rola CA).
  • digitalSignature – zezwala na utworzenie elektronicznego podpisu danych, nie umożliwia natomiast weryfikacji certyfikatu oraz podpisywania certyfikatu i listy CRL.
  • nonRepudiation – zezwala na weryfikację podpisu elektronicznego (danych).
  • keyEncipherment – zezwala na szyfrowanie sekretnego klucza kryptografii symetrycznej (zazwyczaj w certyfikacie serwera).
  • dataEncipherment – zezwala na szyfrowanie danych.
  • keyAgreement – zezwala na wymianę klucza np. metodą DH.

 

> ROZSZERZONE WYKORZYSTANIE KLUCZA


Zadaniem rozszerzenia extendedKeyUsage jest określenie przeznaczenia certyfikatu końcowego. Najistotniejsze wartości to:

 

  • serverAuth – certyfikat serwera TLS WWW, który może być łączony z rozszerzeniem keyUsage: digitalSignature oraz keyEncipherment.
  • clientAuth – certyfikat klienta TLS WWW, może być łączony z rozszerzeniem keyUsage: digitalSignature.
  • codeSigning – certyfikat kodu wykonywalnego, może być łączony z rozszerzeniem keyUsage: digitalSignature.
  • emailProtection – certyfikat szyfrowanej poczty S/MIME, może być łączony z rozszerzeniami keyUsage: digitalSignature, keyEncipherment, nonRepudiation.

 

> INNE PRZYDATNE ROZSZERZENIA


Omówione do tej pory rozszerzenia pozwolą na stworzenie prostego centrum autoryzacji. Osobom zainteresowanym opisywanym tematem polecamy jeszcze kilka przydatnych rozszerzeń:

 

  • subjectAltName – alternatywna nazwa podmiotu rozszerza możliwości pola certyfikatu Subject name. Po jej wprowadzeniu zaleca się, aby w polu Subject name nie wpisywać nazwy domeny lub innego typu adresu, tylko nazwę własną. Alternatywne nazwy tego podmiotu (np. domeny DNS) można umieścić we wspomnianym rozszerzeniu.
  • NameConstraints – rozszerzenie ograniczenia nazw może być użyte tylko w certyfikacie CA i pozwala zawęzić wydawane certyfikaty do wartości określonych w polu Subject name i w ramach nazw alternatywnych. Przykładem zastosowania może być ograniczenie CA tylko do jednej domeny z subdomenami.
  • cRLDistributionPoints – miejsce dystrybucji CRL pozwala zawrzeć w certyfikacie CA odnośnik do listy unieważnionych certyfikatów.
  • CertificatePolicies – polityka certyfikacji pozwala zawrzeć w certyfikacie odnośnik do publicznej polityki, np. wydawania certyfikatów.
  • PolicyMappings – umożliwia w pośrednich centrach certyfikacji zmapowanie swojej polityki do polityki głównego CA.

 

[...]

 

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"