openssl s_client w podstawowym wywołaniu zestawia połączenie TLS, ale nie sprawdza, czy certyfikat pasuje do nazwy, i nie przerywa na błędzie zaufania. Pełny test wymaga trzech opcji naraz - -servername, -verify_hostname i -verify_return_error - oraz jawnie ustalonego zbioru zaufanych CA.
Pełna komenda wygląda tak:
openssl s_client -connect HOST:443 -servername HOST -verify_hostname HOST -verify_return_error -brief </dev/nullHOST zastąp tą samą nazwą DNS we wszystkich trzech miejscach, a 443 to standardowy port HTTPS. Zanim jednak wkleisz to do terminala, zobacz, dlaczego wersja krótsza - ta, którą większość z nas zna z pamięci - potrafi wprowadzić w błąd.
Dlaczego "handshake przeszedł" to za mało?
Po migracji sklepu na nowy serwer admin sprawdza certyfikat z konsoli:
openssl s_client -connect sklep.example:443, ekran zalewa się danymi, na końcu parametry połączenia. Uznaje, że działa, i idzie spać. Rano dzwonią klienci - przeglądarka blokuje stronę. Obie strony mają rację, bo w trzeciej linii tego zalewu był błąd weryfikacji, ales_clientmimo błędu dokończył połączenie. To narzędzie diagnostyczne - jego zadaniem jest zebrać materiał, nie wydać werdykt.
Ta historia to typowy scenariusz pomyłki, nie opis konkretnej awarii - i dokładnie przed nią chroni pełna komenda z początku strony. Zakończony handshake dowodzi tylko tego, że klient i serwer uzgodniły połączenie TLS. Nie dowodzi, że certyfikat pasuje do nazwy, że wystawił go zaufany urząd ani że aplikacja HTTP w ogóle odpowiada.
Co sprawdza podstawowe wywołanie?
Skrócony test połączenia wygląda tak:
openssl s_client -connect HOST:443 -servername HOST -brief </dev/nullTrzy elementy robią tu konkretną robotę:
-connectwskazuje endpoint, czyli adres i port, z którym zestawiasz połączenie.-servernamewpisuje nazwę do rozszerzenia SNI w ClientHello, żeby serwer mógł wybrać właściwy certyfikat.</dev/nulldostarcza koniec wejścia, dzięki czemu komenda kończy się sama zamiast czekać na twoje klawisze;-briefprzycina wynik do podsumowania parametrów.
Tego wywołania używaj do jednego pytania: czy endpoint w ogóle dogaduje TLS z tym klientem. Na pytania o nazwę, zaufanie i działanie strony odpowiada dopiero pełna komenda.
Jak wygląda pełna weryfikacja?
Procedura ma pięć kroków i kolejność ma znaczenie:
- Wybierz miejsce wykonania - warstwę, którą chcesz sprawdzić (o tym niżej).
- Ustal
HOSTna podstawie nazwy, którą wpisuje klient HTTPS, nie adresu serwera. - Zdecyduj, z którego zbioru zaufanych CA korzysta walidacja.
- Uruchom pełną komendę i potraktuj błąd walidacji jako oblany test.
- Dopiero po czystym wyniku przejdź do inspekcji certyfikatów albo testu samej aplikacji.
Przy OpenSSL 3.6.3 na macOS (stan na sierpień 2026) poprawny certyfikat daje w podsumowaniu linie Verification: OK oraz Verified peername: HOST, a komenda zakończy się kodem 0. Błąd nazwy albo zaufania przerywa handshake i zwraca kod różny od zera - i to jest twój wynik testu.
Gdy walidacja ma użyć konkretnego zbioru CA, wskaż go jawnie:
openssl s_client -connect HOST:443 -servername HOST -verify_hostname HOST \
-verify_return_error -CAfile /sciezka/do/CA_BUNDLE -brief </dev/null/sciezka/do/CA_BUNDLE to plik z zaufanymi certyfikatami CA w formacie czytelnym dla OpenSSL. Nie podstawiaj tam certyfikatu ściągniętego z badanego serwera tylko po to, żeby test przeszedł. Zbiór zaufania jest założeniem testu, nie jego wynikiem - inaczej sprawdzasz, czy serwer ufa sam sobie.
Czysty wynik potwierdza dokładnie tyle: tę nazwę, ten endpoint, ten zbiór CA i tę chwilę. Nie potwierdza innych nazw, innych tras sieciowych ani odpowiedzi aplikacji HTTP.
Czym różni się -servername od -verify_hostname?
-servername HOST niczego nie sprawdza. Wpisuje nazwę do SNI w ClientHello, a serwer może jej użyć do wyboru certyfikatu - na jednym adresie IP potrafi siedzieć kilkadziesiąt domen i bez SNI serwer nie wie, którą podać.
Porównanie nazwy z certyfikatem uruchamia dopiero -verify_hostname HOST. OpenSSL zestawia oczekiwaną nazwę DNS z polem Subject Alternative Name, a w starszych certyfikatach z Common Name. Dlatego pełna komenda niesie obie opcje: jedna wpływa na wybór po stronie serwera, druga ocenia tożsamość, którą serwer przedstawił.
W obu miejscach podaj tę samą nazwę - tę, którą wpisuje użytkownik. Adres z -connect może prowadzić do maszyny obsługującej wiele domen, ale tożsamość, o którą pytasz, jest jedna.
Po co -verify_return_error?
Bez tej opcji s_client pokazuje błędy weryfikacji, po czym kontynuuje handshake i przyjmuje łańcuch do diagnostyki. Parametry połączenia na końcu wyniku nie unieważniają błędu z jego początku - a właśnie tak zgubił się admin z historii wyżej.
-verify_return_error odwraca tę logikę: błąd weryfikacji przerywa handshake i wraca jako kod wyjścia polecenia. Każdy skrypt i każdy monitoring, który ma orzekać o certyfikacie, musi mieć tę opcję razem z -verify_hostname i ustalonym zbiorem CA. Nie parsuj tekstu Verify return code z wyniku - kod wyjścia komendy jest tym, na czym opiera się automat.
Skrócony test handshake i pełna weryfikacja pozostają dwoma osobnymi krokami. Pierwszy zbiera materiał, drugi egzekwuje wynik - nie zamieniaj tych ról ani w opisie, ani w automatyzacji.
Skąd uruchomić test?
Miejsce wykonania wyznacza badaną ścieżkę, więc wybierz je świadomie:
- Z sieci użytkownika sprawdzasz publiczny brzeg i trasę, którą widzi klient.
- Z hosta reverse proxy - pośrednika, który przyjmuje ruch z internetu i rozdziela go do aplikacji - sprawdzasz endpoint, DNS i zbiór CA widziane przez proxy.
- Z sieci serwera aplikacji omijasz publiczny brzeg i testujesz połączenie od środka.
Do każdego wyniku zapisz HOST, port i warstwę, z której padła komenda. Dwa hosty potrafią mieć inny DNS, inny routing i inny zbiór zaufanych CA, więc wynik z jednej warstwy nie rozstrzyga o pozostałych. Zmieniaj miejsce wykonania, nie znaczenie opcji - wtedy różnica wyniku wskazuje różnicę ścieżki, a nie inny zakres testu.
Dlaczego trust store jest częścią wyniku?
OpenSSL nie przywozi własnej listy zaufanych urzędów certyfikacji. Ten zbiór - trust store - dostarcza system albo dystrybucja, a każda instalacja może mieć go skonfigurowanego inaczej. Ta sama nazwa i ten sam certyfikat mogą więc przejść walidację na jednym hoście i oblać ją na drugim.
Jeśli korzystasz ze zbioru systemowego, zanotuj środowisko, na którym padła komenda. Jeśli wynik ma być powtarzalny względem wskazanego zestawu CA, dodaj -CAfile. Sama opcja nie dowodzi, że wybrany plik jest właściwy dla twojej organizacji - to decyzja, którą podejmujesz przed testem, nie w jego trakcie.
Co naprawdę pokazuje -showcerts?
openssl s_client -connect HOST:443 -servername HOST -showcerts </dev/null-showcerts wypisuje certyfikaty przesłane przez serwer, w kolejności przesłania. To nie jest zweryfikowany łańcuch - to surowy materiał, który serwer wysłał. Walidacja buduje ścieżkę zaufania z tego materiału i z trust store, a zbudowana ścieżka nie musi pokrywać się z listą jeden do jednego.
Kolejność pracy jest więc stała: najpierw pełna walidacja, potem inspekcja listy. Lista serwera i wynik walidacji to dwa osobne dowody, nawet gdy pochodzą z tego samego endpointu.
Jak odczytać pola certyfikatu?
Podmiot, wystawcę, daty ważności i listę nazw odczytasz potokiem:
openssl s_client -connect HOST:443 -servername HOST </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltNameUruchom go z tej warstwy, której certyfikat chcesz obejrzeć. openssl x509 czyta certyfikat ze standardowego wejścia: -subject pokazuje podmiot, -issuer wystawcę, -dates okres ważności, -ext subjectAltName rozszerzenie SAN, a -noout wyłącza zrzut całego certyfikatu.
Ten potok służy do czytania pól, nie do orzekania. Nie zawiera sprawdzenia nazwy ani zatrzymania na błędzie, więc nie zastępuje pełnej komendy. Pełna walidacja sprawdza przy okazji okres ważności względem bieżącego czasu - odczyt dat robi to tylko dla twoich oczu.
Która komenda czego dowodzi?
| Cel | Komenda lub opcja | Co dowodzi | Czego nie dowodzi |
|---|---|---|---|
| Handshake | s_client -connect HOST:443 -servername HOST -brief |
endpoint uzgodnił TLS z tym klientem | zaufania, zgodności nazwy, działania HTTP |
| SNI | -servername HOST |
ClientHello niesie wskazaną nazwę | dopasowania nazwy do certyfikatu |
| Zgodność nazwy | -verify_hostname HOST |
nazwa sprawdzona wobec SAN albo Common Name | zatrzymania po błędzie |
| Zatrzymanie na błędzie | -verify_return_error |
błąd walidacji przerywa handshake i wraca kodem wyjścia | działania aplikacji HTTP |
| Wskazany zbiór CA | -CAfile /sciezka/do/CA_BUNDLE |
walidacja użyła tego pliku | że to właściwy zbiór dla organizacji |
| Lista certyfikatów | -showcerts |
co i w jakiej kolejności wysłał serwer | kompletnego, zweryfikowanego łańcucha |
| Pola certyfikatu | openssl x509 -noout -subject -issuer -dates -ext subjectAltName |
podmiot, wystawcę, daty, SAN | zgodności nazwy i zaufania |
Każdy wariant komendy ma swoją granicę dowodu - i wniosek, który z niego wyciągasz, nie może tej granicy przekroczyć.
Co zrobić z wynikiem?
Trzy klasy wyników prowadzą w trzy różne strony:
- Brak połączenia transportowego oznacza, że test nie dotarł do certyfikatu. Zanotuj host, port i warstwę - i nie opisuj tego jako błędu certyfikatu, bo skierujesz naprawę w złe miejsce.
- Błąd podczas negocjacji TLS prowadzi do runbooka błędu negocjacji TLS - tam rozkładamy go na przyczyny po stronie serwera i klienta.
- Błąd nazwy, zaufania albo dat wskazuje problem z samym certyfikatem: wydaniem, instalacją albo odnowieniem. Jak działa certyfikat i cały mechanizm TLS, wyjaśniamy w tekście o SSL.
Przekazując wynik dalej, podaj komplet: warstwę wykonania, nazwę z -servername i -verify_hostname, endpoint z -connect oraz użyty zbiór CA. Bez tych czterech danych druga osoba powtórzy podobną komendę na innej ścieżce i będzie debugować inny problem niż ty. Więcej narzędzi tego typu zbieramy w poleceniach do diagnostyki usług serwera.
Pytania o openssl s_client
Co to jest openssl s_client?
openssl s_client to kliencka końcówka SSL/TLS wbudowana w OpenSSL - narzędzie diagnostyczne do łączenia się ze zdalnym endpointem. Pokazuje parametry handshake, certyfikaty przesłane przez serwer i błędy walidacji. Podstawowe wywołanie nie wykonuje jednak pełnej weryfikacji nazwy i zaufania, więc nie zachowuje się jak przeglądarka.
Jak poprawnie zweryfikować certyfikat HTTPS przez s_client?
Użyj razem -servername HOST, -verify_hostname HOST i -verify_return_error, a zaufanie oprzyj na systemowym trust store albo wskaż zbiór przez -CAfile. Czysty wynik potwierdza tę nazwę, ten endpoint, ten zbiór CA i tę chwilę - w miejscu, z którego padła komenda. Nic więcej.
Czy -servername sprawdza nazwę w certyfikacie?
Nie. -servername ustawia SNI w ClientHello, żeby serwer mógł wybrać konfigurację dla wskazanej nazwy. Porównanie nazwy z certyfikatem uruchamia dopiero -verify_hostname. Pełna procedura potrzebuje obu opcji, bo wybór certyfikatu po stronie serwera i ocena przedstawionej tożsamości to dwie osobne operacje.
Czy -showcerts pokazuje zweryfikowany łańcuch?
Nie. -showcerts wypisuje certyfikaty w kolejności, w jakiej wysłał je serwer - i tylko tyle. Ścieżkę zaufania walidacja buduje osobno, z materiału serwera i z trust store, więc może się różnić od tej listy. Listę traktuj jako podgląd tego, co endpoint faktycznie wysyła.
Jak sprawdzić datę ważności certyfikatu?
Przekaż certyfikat z s_client do openssl x509 -noout -dates - dostaniesz pola początku i końca okresu ważności. Sam odczyt dat nie jest walidacją: nie sprawdza nazwy ani zaufania i nie zatrzyma się na błędzie. Do orzekania o certyfikacie wróć do pełnej komendy z początku tej strony.
Opcje i ich zachowanie opisuje dokumentacja OpenSSL 3.x (openssl-s_client, openssl-verification-options, openssl-x509), a port 443 jako standard HTTPS wyznacza rejestr IANA nazw usług i portów.