SSL (Secure Sockets Layer) i TLS (Transport Layer Security) to protokoły kryptograficzne, które zabezpieczają połączenia w Internecie. Choć SSL zostało zastąpione przez TLS, oba protokoły zapewniają bezpieczną transmisję danych.
W codziennej pracy administratora często napotykamy problemy związane z certyfikatami – mogą być one nieprawidłowo skonfigurowane, wygasłe, źle podpisane lub niekompatybilne z wymaganiami aplikacji. W tym wpisie pokażę, jak przeprowadzić podstawową diagnozę takich problemów. Na początek jednak wyjaśnijmy kilka kwestii.
Certyfikaty SSL/TLS – co to takiego?
Certyfikaty SSL/TLS służą do zapewnienia bezpieczeństwa w różnych protokołach komunikacji. Chronią przed przechwyceniem danych, zapewniają integralność przesyłanych informacji i weryfikują tożsamość serwera. Choć najczęściej spotykamy je w HTTPS, są również wykorzystywane w wielu innych aplikacjach i usługach takich jak SMTP, FTP, Kafka, MQTT.
Jednym z najbardziej użytecznych narzędzi do testowania połączeń SSL/TLS i weryfikacji certyfikatów jest openssl s_client
Co to jest openssl s_client
openssl s_client to narzędzie wchodzące w skład pakietu OpenSSL, które działa jako klient SSL/TLS. Pozwala ono na nawiązanie połączenia z serwerem obsługującym SSL/TLS i umożliwia analizę certyfikatów, protokołów szyfrowania, łańcuchów certyfikatów, oraz innych szczegółów dotyczących połączenia. Jest to szczególnie przydatne narzędzie diagnostyczne dla administratorów, którzy chcą upewnić się, że ich serwery oraz aplikacje korzystają z odpowiednich certyfikatów i ustawień bezpieczeństwa.
CA Store – co to i dlaczego jest ważne?
Każdy system operacyjny obsługujący SSL/TLS musi mieć zainstalowany CA store, czyli magazyn certyfikatów instytucji certyfikujących (CA). Kiedy openssl s_client łączy się z serwerem, sprawdza, czy certyfikat serwera został podpisany przez zaufaną CA. Jeśli certyfikat nie jest podpisany przez zaufaną instytucję, połączenie może zostać odrzucone. Przykładowe błędy to: „unable to get local issuer certificate” lub „certificate verify failed”.
CA store może znajdować się w różnych miejscach w systemach operacyjnych:
Debian/Ubuntu:
/etc/ssl/certs/ – katalog zawierający zaufane certyfikaty
/etc/ssl/certs/ca-certificates.crt – pojedynczy plik z listą zaufanych CA
/usr/share/ca-certificates/ – dodatkowe certyfikatyRed Hat/CentOS/Fedora:
/etc/pki/tls/certs/ca-bundle.crt – plik z certyfikatami CA
/etc/pki/ca-trust/extracted/ – katalog, w którym znajdują się wyodrębnione certyfikatyIBM AIX
/var/ssl/certs/ – domyślny katalog z certyfikatami
/var/ssl/certs/ca-bundle.crt – plik zawierający listę zaufanych CA
/opt/freeware/etc/ssl/certs/ – dla OpenSSL dostarczonego z pakietów AIX ToolboxMicrosoft Windows
certlm.msc → "Zaufane główne urzędy certyfikacji"
Lokalizacja w rejestrze:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\Jak działa CA Store?
Po nawiązaniu połączenia SSL/TLS, serwer wysyła swój certyfikat do klienta. Klient (np. openssl s_client) sprawdza, czy certyfikat serwera jest podpisany przez zaufaną CA. Jeśli tak, połączenie jest uznane za bezpieczne, w przeciwnym razie może pojawić się błąd.
W skrócie o PKI, CA i Łańcuchu certyfikacji
PKI (Public Key Infrastructure) to system zarządzania kluczami kryptograficznymi, który zapewnia bezpieczeństwo komunikacji. W ramach tego systemu funkcjonuje łańcuch certyfikacji, w którym certyfikat serwera jest podpisany przez pośrednie certyfikaty, a ostatecznie przez główny certyfikat (root CA). Weryfikacja tego łańcucha zapewnia, że certyfikat serwera jest autentyczny i zaufany. CA (Certificate Authority), czyli zaufana instytucja odpowiedzialna za wydawanie certyfikatów cyfrowych, pełni kluczową rolę w tym procesie, podpisując certyfikaty, co pozwala na ich weryfikację i zapewnia, że połączenie jest bezpieczne.
Przykłady użycia openssl s_client
Poniżej znajdziesz przykłady, jak diagnozować i testować połączenia SSL/TLS oraz weryfikować certyfikaty na swoim systemie. Dzięki openssl s_client możesz sprawdzić szczegóły połączenia, łańcuch certyfikatów, protokoły szyfrowania i wiele więcej.
1. Podstawowe połączenie z serwerem SSL/TLS
Komenda:
openssl s_client -connect osadmins.com:443Opis:
Nawiązuje połączenie z serwerem osadmins.com na porcie 443 (standardowy port HTTPS) i wyświetla certyfikat SSL/TLS.
Output:
Connecting to 94.23.89.116
CONNECTED(00000005)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R10
verify return:1
depth=0 CN=www.osadmins.com
verify return:1
Server certificate
-----BEGIN CERTIFICATE-----
MIIE/TCCA+WgAwIBAgISAzmyHu6wrYhbImEhWwu9BeSVMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNSMTAwHhcNMjUwMTI1MTY1MzIwWhcNMjUwNDI1MTY1MzE5WjAbMRkwFwYDVQQD
ExB3d3cub3NhZG1pbnMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAuWJfIyYL0uFz2slDAvpNiFagDokWBZXjGB2XniOYJJxbuTP2s2VuMymTKCbJ
Q7TqTFOAwpuqzForg0cxzUycEC189O5G9SUSm5L6NshFFX0xkNgXhCyQAA6mlaV0
FgyIw1sC3aY0Ntmbu4ad22LbxQa6GiIfqSgtmsMCqbwJbM6km8HrpO9XwaoDrnfF
nHIgafxfD+SmUBaeeRR+M84GnKSBaCU8vHqVI9fsVKIxYxLFtAsLAE2+6kwQpnmI
FQNhcgscRpeJg2UvYihpPsbLARLY40EE7ZuejCvTm9rSfqTUYEB9NykmUgW39VuZ
e6Lafi6qn4Vh9kxv6OFCyoYngwIDAQABo4ICITCCAh0wDgYDVR0PAQH/BAQDAgWg
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0G
A1UdDgQWBBSoutk0w86IIRxPTXIJBhEbPST0tDAfBgNVHSMEGDAWgBS7vMNHpeS8
qcbDpHIMEI2iNeHI6DBXBggrBgEFBQcBAQRLMEkwIgYIKwYBBQUHMAGGFmh0dHA6
Ly9yMTAuby5sZW5jci5vcmcwIwYIKwYBBQUHMAKGF2h0dHA6Ly9yMTAuaS5sZW5j
ci5vcmcvMCkGA1UdEQQiMCCCDG9zYWRtaW5zLmNvbYIQd3d3Lm9zYWRtaW5zLmNv
bTATBgNVHSAEDDAKMAgGBmeBDAECATCCAQMGCisGAQQB1nkCBAIEgfQEgfEA7wB2
AHMgIg8IFor588SmiwqyappKAO71d4WKCE0FANSlQkRZAAABlJ6XaIIAAAQDAEcw
RQIhAM7716cKAcSw3UxBqBoB3YuL6pkwgt+LMIyr5cuRUXoXAiAYpTYxtfukmQ+o
6pWBFlYpo9CYn8fjLBlNJwsSW4gsIQB1AM8RVu7VLnyv84db2Wkum+kacWdKsBfs
rAHSW3fOzDsIAAABlJ6XaLkAAAQDAEYwRAIgS1trDjTWAQrV6NLGMynLlo+3Gvxl
PPyXqcj5zHGWaCMCIARmn5V66pf7XBmQOWDuVpSoIhMc6aI2hA2NnfuP3scmMA0G
CSqGSIb3DQEBCwUAA4IBAQC6URHhDTOtmFABeNmvK+AJuI5TEl9PMqcmvXD6kcjL
MAKQCzH0WQokZw3x1Y5KatzSucupvXaqgB/RBfkYM3P783FrHJKlmQCZ8LVJwEOD
1sh82Wzx7TSvsNfDzv3JWoIsXOkSK9aPhx2F4ukugBFr4DJGfOQsyV/5mCu2OqZg
MzE2lJoV6v+iKZ6j0bMTOvTBGBopaHJ6sUrsMiOHX+SPcTR+3aiZh7Cdax+V/iWM
s4DlRlT2yasXQwSG7uOxM0MIfp3HOqKBWNc2Bo4YnD3LOJW4PjIGD59/Uq8+GvhQ
wDhCRtyDlxkfXyHta3/YQt1Qb8aWeDH4Tpo47Td2Wz3H
-----END CERTIFICATE-----
subject=CN=www.osadmins.com
issuer=C=US, O=Let's Encrypt, CN=R10
SSL handshake has read 3135 bytes and written 403 bytes
Verification: OK
DONEWyjaśnienie:
Widzimy, że klient nawiązał połączenie z serwerem 94.23.89.116 na porcie 443, a certyfikat serwera został poprawnie zweryfikowany. Certyfikat serwera znajduje się pomiędzy znacznikami -----BEGIN CERTIFICATE----- i -----END CERTIFICATE-----. Jest on w tej chwili nieczytelny, ponieważ jest zakodowany w formacie PEM. Certyfikat serwera jest podpisany przez pośrednie certyfikaty Lets Encrypt R10 oraz główny certyfikat ISRG Root X1. Te certyfikaty są częścią łańcucha certyfikacji, który zapewnia zaufanie do certyfikatu serwera, ale nie są certyfikatami samego serwera. Połączenie zostało nawiązane z wykorzystaniem protokołu TLS 1.3 i szyfrowania TLS_AES_256_GCM_SHA384, a klucz RSA ma długość 2048 bitów. Weryfikacja certyfikatu zakończyła się sukcesem (Verify return code: 0 (ok)), co potwierdza jego poprawność i zaufanie. Serwer nie wymaga certyfikatu klienta (brak mTLS) – To oznacza, że serwer nie wymaga uwierzytelnienia klienta za pomocą certyfikatu (tzw. mutual TLS – mTLS). W standardowym połączeniu SSL/TLS tylko serwer przedstawia swój certyfikat, a klient go weryfikuje. W przypadku mTLS zarówno serwer, jak i klient muszą przedstawić swoje certyfikaty i wzajemnie się uwierzytelnić.
2. Pokazanie pełnego łańcucha certyfikatów
Komenda:
openssl s_client -connect osadmins.com:443 -showcertsOpis: Wyświetla pełny łańcuch certyfikatów serwera, w tym certyfikat serwera oraz ewentualne certyfikaty pośrednie.
Output:
Connecting to 94.23.89.116
CONNECTED(00000005)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R10
verify return:1
depth=0 CN=www.osadmins.com
verify return:1
--BEGIN CERTIFICATE-----
MIIE/TCCA+WgAwIBAgISAzmyHu6wrYhbImEhWwu9BeSVMA0GCSqGSIb3DQEBCwUA
-----END CERTIFICATE-----
1 s:C=US, O=Let's Encrypt, CN=R10
i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
-----BEGIN CERTIFICATE-----
MIIFBTCCAu2gAwIBAgIQS6hSk/eaL6JzBkuoBI110DANBgkqhkiG9w0BAQsFADBP
-----END CERTIFICATE-----
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)Wyjaśnienie:
Pokazuje pełny łańcuch certyfikatów serwera, w tym certyfikat główny i certyfikaty pośrednie, które pomagają w weryfikacji autentyczności certyfikatu serwera.
4. Sprawdzenie szczegółów certyfikatu
Komenda:
openssl s_client -connect osadmins.com:443 </dev/null | openssl x509 -noout -text
Opis: Wyświetla szczegóły certyfikatu, takie jak jego podmiot, wystawca, numer seryjny i algorytmy.
Output:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:39:b2:1e:ee:b0:ad:88:5b:22:61:21:5b:0b:bd:05:e4:95
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=R10
Validity
Not Before: Jan 25 16:53:20 2025 GMT
Not After : Apr 25 16:53:19 2025 GMT
Subject: CN=www.osadmins.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b9:62:5f:23:26:0b:d2:e1:73:da:c9:43:02:fa:
4d:88:56:a0:0e:89:16:05:95:e3:18:1d:97:9e:23:
...
Wyjaśnienie:
Wyświetla szczegółowe informacje o certyfikacie, takie jak dane właściciela certyfikatu, okres ważności oraz algorytmy szyfrowania. Komenda openssl s_client -connect osadmins.com:443 </dev/null | openssl x509 -noout -text działa w dwóch etapach:
Najpierw, za pomocą openssl s_client -connect osadmins.com:443 </dev/null, nawiązywane jest połączenie SSL/TLS z serwerem osadmins.com na porcie 443 (domyślny port dla HTTPS). Następnie wynik tego połączenia jest przekazywany do drugiej części komendy, czyli openssl x509 -noout -text.
Część openssl x509 -noout -text służy do wyświetlenia szczegółowych informacji o certyfikacie serwera w formacie tekstowym. Opcja -noout powoduje, że nie zostanie wyświetlony sam zakodowany certyfikat (w formacie PEM), a tylko jego czytelne dane. Parametr -text zapewnia pełne wyświetlenie informacji o certyfikacie, takich jak dane właściciela, okres ważności, algorytm podpisu, publiczny klucz i inne szczegóły.
Podsumowując, ta komenda łączy się z serwerem, pobiera certyfikat SSL, a następnie wyświetla jego szczegóły w formacie tekstowym.
5. Weryfikacja certyfikatu za pomocą pliku CA
Komenda:
openssl s_client -connect osadmins.com:443 -CAfile /path/to/cacert.pem
Opis: Weryfikuje certyfikat serwera, używając zdefiniowanego pliku certyfikatu zaufanej instytucji certyfikującej (CA).
Output:
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=osadmins.com
i:/C=US/O=Let's Encrypt/CN=R3
...
Verify return code: 0 (ok)
Wyjaśnienie: Jeśli certyfikat serwera jest podpisany przez zaufaną instytucję, wówczas weryfikacja zakończy się sukcesem, a wynik będzie Verify return code: 0 (ok). Przełącznik -CAfile /path/to/cacert.pem określa ścieżkę do pliku z certyfikatem głównym (CA), który zawiera zaufane certyfikaty certyfikacji, które mają być używane do weryfikacji certyfikatu serwera. Zamiast polegać na domyślnym magazynie certyfikatów systemowych, użytkownik dostarcza własny plik certyfikatu (np. cacert.pem), który zawiera certyfikaty CA, które uznaje za zaufane.
6. Testowanie połączenia z użyciem TLS 1.2
Komenda:
openssl s_client -connect osadmins.com:443 -tls1_2
Opis: Testuje połączenie z serwerem, wymuszając użycie protokołu TLS 1.2.
Output:
CONNECTED(00000003)
---
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Wyjaśnienie: Pokazuje, że połączenie zostało nawiązane przy użyciu TLS 1.2 oraz wskazuje zastosowany algorytm szyfrowania.
7. Sprawdzenie połączenia FTPS
Komenda:
openssl s_client -connect osadmins.com:990
Opis: Testuje połączenie FTPS (FTP z SSL/TLS) na porcie 990.
Output:
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=osadmins.com
i:/C=US/O=Let's Encrypt/CN=R3
...
Wyjaśnienie:
Połączenie zostało nawiązane z serwerem FTPS, a wynik zawiera certyfikaty i inne szczegóły połączenia.
Oczywiście, poniżej znajdziesz kilka bardziej zaawansowanych i mniej trywialnych przykładów użycia openssl s_client:
8. Wymuszenie użycia konkretnego algorytmu szyfrowania
Komenda:
openssl s_client -connect osadmins.com:443 -cipher ECDHE-RSA-AES128-GCM-SHA256
Opis: Wymusza nawiązanie połączenia z serwerem przy użyciu określonego algorytmu szyfrowania (w tym przypadku ECDHE-RSA-AES128-GCM-SHA256). Może być przydatne do testowania, czy serwer wspiera określony algorytm szyfrowania.
Output:
CONNECTED(00000003)
---
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Wyjaśnienie: Połączenie zostało nawiązane z serwerem przy użyciu wskazanego algorytmu szyfrowania, jeśli jest on obsługiwany przez serwer.
9. Testowanie połączenia z serwerem przy użyciu niestandardowego portu
Komenda:
openssl s_client -connect osadmins.com:8443
Opis: Nawiązuje połączenie SSL/TLS z serwerem, który nasłuchuje na niestandardowym porcie (w tym przypadku 8443, często używanym do HTTPS na alternatywnych portach).
Output:
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=osadmins.com
i:/C=US/O=Let's Encrypt/CN=R3
...
Wyjaśnienie: To przydatne, gdy serwer SSL/TLS nie działa na standardowym porcie 443, ale na innym porcie, który wymaga testów.
10. Sprawdzenie pełnego procesu handshaku SSL/TLS z pełnym logiem (debugowanie)
Komenda:
openssl s_client -connect osadmins.com:443 -debug
Opis: Włącza tryb debugowania, który pozwala śledzić cały proces nawiązywania połączenia SSL/TLS. Zawiera szczegóły dotyczące wymiany danych, takie jak handshake, wymiana kluczy itp.
Output:
CONNECTED(00000003)
>>> TLS 1.2 Handshake [length 3038]
...
<<< TLS 1.2 Handshake [length 0000]
Wyjaśnienie: Tryb debugowania dostarcza szczegółowych informacji na temat samego procesu nawiązywania połączenia SSL/TLS, co może pomóc w diagnozowaniu problemów z certyfikatami, protokołami czy algorytmami szyfrowania.
12. Testowanie z użyciem własnych certyfikatów klienta (weryfikacja dwukierunkowa)
Komenda:
openssl s_client -connect osadmins.com:443 -cert /path/to/client-cert.pem -key /path/to/client-key.pem
Opis: Nawiązuje połączenie SSL/TLS przy użyciu własnego certyfikatu i klucza prywatnego klienta (przydatne w przypadku, gdy serwer wymaga uwierzytelnienia dwukierunkowego, np. w API).
Output:
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=client.com
i:/C=US/O=My Custom CA/CN=My Custom Root CA
...
Wyjaśnienie: Połączenie jest nawiązywane przy użyciu certyfikatu klienta, co może być wymagane w środowiskach, które korzystają z dwukierunkowego uwierzytelniania SSL/TLS.
Przedstawione komendy to podstawowe sposoby na sprawdzanie połączenia z serwerem za pomocą certyfikatów SSL/TLS. Umożliwiają one weryfikację poprawności certyfikatu serwera, sprawdzenie jego szczegółów oraz upewnienie się o bezpieczeństwie połączenia. Narzędzia takie jak openssl s_client i openssl x509 pozwalają na analizę certyfikatów i łańcucha certyfikacji, co jest kluczowe dla zapewnienia zaufania w komunikacji sieciowej.