Kort svar
Brug openssl s_client -connect HOST:443 -servername HOST som dit udgangspunkt. Outputtet fortæller dig fremforhandlet protokol og cipher, viser certifikat-kæden serveren sendte, og giver en Verify return code der peger direkte på årsagen. Næsten alle de fejl vi dækker i denne serie kan diagnosticeres med varianter af denne ene kommando.
Grundkommandoen
openssl s_client -connect example.com:443 -servername example.com
-servername sender SNI, så du rammer det rigtige certifikat på servere med flere domæner — udelad det aldrig. Tilføj </dev/null eller echo | foran for at lukke forbindelsen automatisk i stedet for at hænge.
Læs de fire vigtigste linjer
| Linje | Hvad den fortæller |
|---|---|
Protocol : | Den fremforhandlede TLS-version (fx TLSv1.3) |
Cipher : | Den valgte cipher suite |
Certificate chain | Hvor mange certifikater serveren sendte (kæden) |
Verify return code: | 0 = OK; alt andet er en valideringsfejl |
Opskrifter til konkrete problemer
# Tving en bestemt protokol (test om 1.0/1.1 stadig er åben) openssl s_client -connect example.com:443 -tls1_2 openssl s_client -connect example.com:443 -tls1_3 # Se hele kæden serveren sender (tæl certifikaterne) openssl s_client -connect example.com:443 -servername example.com -showcerts # Læs udløbsdatoer, subject og issuer echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -dates -subject -issuer # Se hvilke navne (SAN) certifikatet dækker echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -text | grep -A1 "Subject Alternative Name" # Validér mod en specifik root (intern CA / inspektions-proxy) openssl s_client -connect internal.example.com:443 -CAfile corporate-root.crt # Send et client certificate (mTLS) openssl s_client -connect api.example.com:443 -servername api.example.com \ -cert client.crt -key client.key
Verify return codes du vil støde på
- 0 — OK.
- 10 — certifikatet er udløbet.
- 18 / 19 — selvsigneret certifikat (i kæden).
- 20 — manglende issuer (intermediate mangler).
- 21 — kunne ikke verificere det første certifikat (ofte samme rod-årsag som 20).
Andre værktøjer i samme værktøjskasse
Til ciphers er nmap --script ssl-enum-ciphers -p 443 host og testssl.sh hurtigere end at gætte. Til en pæn rapport kan SSL Labs bruges på offentlige hosts. Men til det daglige "hvorfor fejler denne ene forbindelse" er s_client stadig kongen — se også guiden til handshake-fejl.
Fra engangs-debug til løbende overvågning
s_client er perfekt når du allerede ved hvilken host der driller. Det skalerer bare ikke til hundredvis af endpoints. CertControl kører den samme slags kontrol — protokol, cipher, kæde, udløb — kontinuerligt på alle jeres endpoints og rejser en finding når noget afviger, så I ikke skal nå at køre kommandoen manuelt før en bruger opdager fejlen.
Ofte stillede spørgsmål
Hvorfor hænger openssl s_client uden at returnere?
Fordi forbindelsen holdes åben og venter på input. Skriv echo | openssl s_client ... eller tilføj </dev/null, så lukkes den automatisk efter handshaken.
Hvad gør -servername præcist?
Det sender SNI (Server Name Indication), så serveren ved hvilket domæne du beder om. Uden det får du standardcertifikatet på servere med flere domæner — en hyppig kilde til forvirring.
Kan jeg bruge s_client til at teste en mailserver?
Ja. Brug -starttls smtp (eller imap/pop3) og den relevante port, fx -connect mail.example.com:587 -starttls smtp.
Hvad betyder Verify return code: 0?
At klienten kunne bygge en gyldig kæde fra serverens certifikat op til en betroet root, og at certifikatet er gyldigt for navnet. Med andre ord: valideringen lykkedes.