Przeglądanie zawartości certyfikatu:

W diagnostyce TLS jedną z najważniejszych potrzeb może być wyświetlenie zawartości certyfikatu. Jest to przydatne, gdy chcesz potwierdzić datę upływu terminu ważności certyfikatu (częsta przyczyna problemów z TLS) lub dowiedzieć się, dla jakich witryn określony certyfikat jest ważny. Poniższe polecenie zwraca wszystkie dane wewnątrz certyfikatu:

openssl x509 -in /ścieżka/do/cert.crt -noout -text

Przeglądanie zawartości żądania CSR:

Po wygenerowaniu żądania CSR lub przed wysłaniem starego żądania CSR w centrum certyfikacji w celu odnowienia certyfikatu warto przejrzeć zawartość żądania CSR, aby się upewnić, czy zawiera poprawną listę hostów. Wymaga to wykonania nieco innego polecenia OpenSSL:

openssl req -in /ścieżka/do/certrequest.csr -noout -text

Rozwiązywanie problemów w komunikacji z TLS:

Jest to chyba jedno z najbardziej przydatnych poleceń OpenSSL w przypadku, gdy próbujemy rozwiązywać problemy z usługami zabezpieczonymi za pomocą szyfrowania TLS. Normalne polecenia do rozwiązywania problemów z sieciami, takie jak telnet lub nc, nie działają z usługami TLS, ponieważ w ich przypadku nie da się właściwie przeprowadzić procesu handshake. W tych przypadkach można skorzystać z OpenSSL w celu zainicjowania prawidłowego połączenia TLS ze zdalną usługą, a następnie użyć wiersza polecenia, gdzie można wprowadzać surowe polecenia HTTP, SMTP, FTP lub inne. Na przykład, aby połączyć się z usługą HTTPS example.com, która nasłuchuje w porcie 443, po to aby móc wpisywać surowe polecenia HTTP w celu rozwiązywania problemów, można skorzystać z takiego oto polecenia:

openssl s_client -connect example.com:443

Certyfikaty w formacie .pfx

openssl pkcs12 -in certyfyikat.pfx -out nowy_cert.pem -nodes -nokeys – generuje nam certyfikat.

openssl pkcs12 -in certyfikat.pfx -out nowy_klucz.pem -nocerts – generuje nam nowy klucz

*****************************************************************************

1) Generowanie klucza prywatnego centrum certyfikacji CA:

openssl genrsa -des3 -out private/cakey.pem 4096

2) Wygenerowanie Certyfikatu CA:

openssl req -new -x509 -days 365 -key private/cakey.pem -out cacert.pem

3) W celu wystawienia certyfikatu dla podmiotu (serwera) trzeba podpisać jego wniosek:

openssl ca -notext -in serverreq.pem -out servercert.pem

4) Ściąganie hasła z klucza prywatnego serwera

openssl rsa -in private/serverkey.pem -out private/serverkey.pem_bezhasla

5) Uniewaznienie certyfikatow:

openssl ca -revoke jkowalskicert.pem

6) W celu wygenerowania listy certyfikatów unieważnionych:

openssl ca -gencrl -out crl.pem

7) Sprawdzanie waznosci certyfikatu:

openssl x509 -noout -text -in user.crt

8) Konwersja certyfikatow do innych rozszerzen:

PEM (cert) DER (cert) openssl x509 -in cert.pem -out cert.der -outform DER
DER (cert) PEM (cert) openssl x509 -in cert.der inform DER –out cert.pem -outform PEM
DER (key) PEM (key) openssl rsa in input.key inform DER out output.key outform PEM
PEM (key, cert) PKCS#12 openssl pkcs12 -export -out cert.p12 -inkey userkey.pem -in usercert.pem
PKCS#12 PEM (cert) openssl pkcs12 -clcerts -nokeys –in cert.p12 -out usercert.pem
PKCS#12 PEM (key) openssl pkcs12 -nocerts -in cert.p12 –out userkey.pem

Przebieg nawiązania połączenia SSL:

Zanim protokoły warstwy aplikacji będą mogły wymieniać dane w bezpieczny sposób, mus nastąpić nawiązanie sesji SSL (ang. SSL handshake). Na SSL handshake składa się kilka faz negocjacji, które przedstawiono kolejno w punktach.
1. Klient łączy się z serwerem i wysyła pakiet początkowy Hello, a wraz z nim numer obsługiwanej wersji SSL, obsługiwane algorytmy szyfrujące, algorytmy kompresji oraz losowy numer związany z rozpoczętą sesją (ID).
2. Serwer w odpowiedzi wysyła klientowi numer obsługiwanej wersji SSL, obsługiwane algorytmy szyfrujące, a także swój certyfikat (klucz publiczny).
3. Na tym etapie klient sprawdza certyfikat serwera — czy jest ważny oraz czy
wystawił go zaufany urząd (CA). Protokół SSL przewiduje także możliwość wysłania przez serwer żądania o uwierzytelnienie klienta. Uwierzytelnianie to jest opcjonalne i stosuje się je w określonych warunkach.
4. W przypadku pozytywnego uwierzytelnienia serwera klient generuje 48-bajtową liczbę zwaną „pre-master secret” i szyfruje ją, używając przy tym klucza publicznego serwera (zawartego w certyfikacie serwera). Liczba „pre-master” składa się z 2 bajtów identyfikujących klienta oraz 46 bajtów losowych.
5. Serwer po otrzymaniu liczby „pre-master” odszyfrowuje ją, używając do tego swojego klucza prywatnego, i porównuje pierwsze 2 bajty identyfikujące klienta z danymi, które otrzymał w inicjacyjnym pakiecie Hello.
6. Jeśli jest wymagane uwierzytelnienie klienta, jest to robione w tej chwili. Wówczas klient musi przesłać swój certyfikat.
7. Na podstawie już wymienionych danych (m.in. pre-master key, losowe dane wygenerowane w punkcie 1.) serwer i klient generują tzw. master key (znany tylko im).
8. Zarówno klient, jak i serwer na podstawie master-key generują symetryczne
klucze sesyjne, które umożliwiają im szyfrowanie i sprawdzanie integralności przesyłanych danych1.

Na podstawie master-key generowanych jest sześć kluczy — trzy w kierunku serwer-klient i trzy w drugą stronę. Klucze te służą do szyfrowania i sprawdzania integralności danych. Zainteresowanych Czytelników odsyłam do dokumentacji dostępnej na stronie korporacji Netscape: http://wp.netscape.com/eng/ssl3/draft302.txt.

9) Tworzenie Diffie-Helman 8194

openssl dhparam -out /etc/ssl/proton.edu.pl/dhparam.pem 8194

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.