SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that secure connections on the Internet. While SSL has been replaced by TLS, both protocols provide secure data transmission.
[gspeech]In everyday work, there are often issues with certificates – they can be incorrectly configured, expired, improperly signed, or incompatible with application requirements. This post will show how to perform an initial diagnosis of such problems.
What are SSL/TLS Certificates?
SSL/TLS certificates are used to ensure security across various protocols. They protect against data interception, ensure the integrity of transmitted information, and verify the identity of the server. While they are most commonly seen in HTTPS, they are also used in many other applications and services such as SMTP, FTP, Kafka, MQTT.
One of the most useful tools for testing SSL/TLS connections and verifying certificates is OpenSSL’s s_client.
What is OpenSSL s_client?
OpenSSL s_client is a tool included in the OpenSSL package that functions as an SSL/TLS client. It allows establishing a connection with a server that supports SSL/TLS and enables the analysis of certificates, encryption protocols, certificate chains, and other connection details. This is an especially useful diagnostic tool for administrators who want to ensure that their servers and applications are using the correct certificates and security settings.
CA Store – What is it and why is it important?
Every operating system that supports SSL/TLS needs to have a CA store, which is a repository of certificates from Certificate Authorities (CAs). When openssl s_client connects to a server, it checks whether the server’s certificate has been signed by a trusted CA. If the certificate is not signed by a trusted institution, the connection may be rejected. Some common errors include “unable to get local issuer certificate” or “certificate verify failed”.
The CA store can be located in different places across operating systems:
Debian/Ubuntu:
/etc/ssl/certs/ – directory containing trusted certificates
/etc/ssl/certs/ca-certificates.crt – a single file with the list of trusted CAs
/usr/share/ca-certificates/ – additional certificatesRed Hat/CentOS/Fedora:
/etc/pki/tls/certs/ca-bundle.crt – file with CA certificates
/etc/pki/ca-trust/extracted/ – directory containing extracted certificatesIBM AIX:
/var/ssl/certs/ – default directory for certificates
/var/ssl/certs/ca-bundle.crt – file containing the list of trusted CAs
/opt/freeware/etc/ssl/certs/ – for OpenSSL provided by AIX Toolbox packagesMicrosoft Windows:
certlm.msc → "Trusted Root Certification Authorities"
Registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\How does the CA Store work?
After establishing an SSL/TLS connection, the server sends its certificate to the client. The client (e.g., openssl s_client) checks if the server’s certificate is signed by a trusted CA. If so, the connection is deemed secure; otherwise, an error might appear.
In Brief about PKI, CA, and Certificate Chain
PKI (Public Key Infrastructure) is a system for managing cryptographic keys that ensures secure communication. Within this system, there is a certification chain in which the server’s certificate is signed by intermediate certificates and ultimately by the root certificate (root CA). Verifying this chain ensures that the server’s certificate is authentic and trusted. CA (Certificate Authority), the trusted entity responsible for issuing digital certificates, plays a crucial role in this process by signing certificates, which allows their verification and ensures that the connection is secure.
Examples of Using openssl s_client
Below are examples of how to diagnose and test SSL/TLS connections and verify certificates on your system. With openssl s_client, you can check connection details, certificate chains, encryption protocols, and much more.
1. Basic SSL/TLS Connection to the Server
Command:
openssl s_client -connect osadmins.com:443Description: This command establishes a connection to the osadmins.com server on port 443 (the default HTTPS port) and displays the SSL/TLS certificate.
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
---
Certificate chain
0 s:CN=www.osadmins.com
i:C=US, O=Let's Encrypt, CN=R10
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Jan 25 16:53:20 2025 GMT; NotAfter: Apr 25 16:53:19 2025 GMT
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
---
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
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3135 bytes and written 403 bytes
Verification: OK
---
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)Explanation:
This shows the full certificate chain of the server, including the server certificate and any intermediate certificates, which help verify the authenticity of the server’s certificate.
2. Show the Full Certificate Chain
Command:
openssl s_client -connect osadmins.com:443 -showcertsDescription: Displays the full certificate chain of the server, including the server certificate and any intermediate certificates.
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
---
Certificate chain
0 s:CN=www.osadmins.com
i:C=US, O=Let's Encrypt, CN=R10
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Jan 25 16:53:20 2025 GMT; NotAfter: Apr 25 16:53:19 2025 GMT
-----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-----
---
Server certificate
subject=CN=www.osadmins.com
issuer=C=US, O=Let s Encrypt, CN=R10
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3135 bytes and written 403 bytes
Verification: OK
---
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)Explanation:
Displays the complete certificate chain, including the main and intermediate certificates, which help validate the server certificate.
3. Check the Server’s SSL Certificate Expiry Date
Command:
openssl s_client -connect osadmins.com:443 </dev/null | openssl x509 -noout -datesDescription: After connecting to the server, this command extracts the expiration dates of the SSL/TLS certificate.
Output:
notBefore=Jan 1 00:00:00 2023 GMT
notAfter=Jan 1 23:59:59 2024 GMTExplanation: Shows the start and end dates of the certificate’s validity. Useful for checking if the certificate has expired.
4. Checking Certificate Details
Command:
openssl s_client -connect osadmins.com:443 </dev/null | openssl x509 -noout -textDescription: Displays the details of the certificate, such as its subject, issuer, serial number, and algorithms.
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:
...Explanation:
Displays detailed information about the certificate, such as the certificate holder’s data, validity period, and encryption algorithms. The command openssl s_client -connect osadmins.com:443 </dev/null | openssl x509 -noout -text works in two stages:
First, using openssl s_client -connect osadmins.com:443 </dev/null, an SSL/TLS connection is established with the server osadmins.com on port 443 (the default HTTPS port). Then the result of this connection is passed to the second part of the command, openssl x509 -noout -text.
The openssl x509 -noout -text part is used to display the detailed information of the server’s certificate in a human-readable text format. The -noout option ensures that the actual encoded certificate (in PEM format) is not displayed, only the readable data. The -text parameter ensures that the certificate information, such as the owner’s data, validity period, signature algorithm, public key, and other details, are fully displayed.
In summary, this command connects to the server, retrieves the SSL certificate, and then displays its details in a readable format.
5. Verifying the Certificate Using a CA File
Command:
openssl s_client -connect osadmins.com:443 -CAfile /path/to/cacert.pemDescription: Verifies the server’s certificate using a specified trusted Certificate Authority (CA) certificate file.
Output:
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=osadmins.com
i:/C=US/O=Let's Encrypt/CN=R3
...
Verify return code: 0 (ok)Explanation: If the server’s certificate is signed by a trusted authority, the verification will succeed, and the result will be Verify return code: 0 (ok). The -CAfile /path/to/cacert.pem switch specifies the path to a file containing the trusted root certificate (CA), which contains the certification authorities used for verifying the server’s certificate. Instead of relying on the system’s default certificate store, the user provides their own certificate file (e.g., cacert.pem) containing the trusted CA certificates.
6. Testing Connection with TLS 1.2
Command:
openssl s_client -connect osadmins.com:443 -tls1_2Description: Tests the connection to the server, forcing the use of TLS 1.2.
Output:
CONNECTED(00000003)
---
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256Explanation: Shows that the connection was established using TLS 1.2, and it indicates the encryption algorithm used.
7. Checking FTPS Connection
Command:
openssl s_client -connect osadmins.com:990Description: Tests the FTPS connection (FTP with SSL/TLS) on port 990.
Output:
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=osadmins.com
i:/C=US/O=Let's Encrypt/CN=R3
...Explanation:
The connection was established with the FTPS server, and the output includes certificates and other connection details.
Below, you will find a few more advanced and less trivial examples of using openssl s_client.
8. Forcing the Use of a Specific Encryption Algorithm
Command:
openssl s_client -connect osadmins.com:443 -cipher ECDHE-RSA-AES128-GCM-SHA256Description: Forces the connection to be established with the server using a specific encryption algorithm (in this case, ECDHE-RSA-AES128-GCM-SHA256). This can be useful to test whether the server supports a particular encryption algorithm.
Output:
CONNECTED(00000003)
---
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256Explanation: The connection is established with the server using the specified encryption algorithm if it is supported by the server.
9. Testing Connection to the Server Using a Custom Port
Command:
openssl s_client -connect osadmins.com:8443Description: Establishes an SSL/TLS connection with a server listening on a non-standard port (in this case, port 8443, often used for HTTPS on alternate ports).
Output:
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=osadmins.com
i:/C=US/O=Let's Encrypt/CN=R3
...Explanation: This is useful when the SSL/TLS server does not run on the standard port 443 but on another port that needs testing.
10. Checking the Full SSL/TLS Handshake Process with Full Logs (Debugging)
Command:
openssl s_client -connect osadmins.com:443 -debugDescription: Enables debugging mode, which allows you to track the entire SSL/TLS connection process. It includes details about data exchanges such as the handshake, key exchanges, etc.
Output:
CONNECTED(00000003)
>>> TLS 1.2 Handshake [length 3038]
...
<<< TLS 1.2 Handshake [length 0000]Explanation: Debugging mode provides detailed information about the SSL/TLS connection process itself, which can help diagnose issues with certificates, protocols, or encryption algorithms.
11. Testing with Custom Client Certificates (Mutual Authentication)
Command:
openssl s_client -connect osadmins.com:443 -cert /path/to/client-cert.pem -key /path/to/client-key.pemDescription: Establishes an SSL/TLS connection using your own client certificate and private key (useful when the server requires mutual authentication, such as in APIs).
Output:
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=client.com
i:/C=US/O=My Custom CA/CN=My Custom Root CA
...Explanation: The connection is established using the client certificate, which may be required in environments that use mutual SSL/TLS authentication.