Inspect remote TLS certificates from the command line

Use openssl s_client to retrieve a remote server's certificates and openssl x509 to inspect the leaf. curl -vI is convenient for a quick HTTPS connection check, while Nmap's ssl-cert script can inventory several authorized targets.

Inspect the certificate with OpenSSL

openssl s_client -showcerts -servername example.com \
  -connect example.com:443 </dev/null \
  | openssl x509 -noout -text

The output includes subject, issuer, validity dates, Subject Alternative Names (SAN), public-key information, and signature algorithm. The x509 command reads the first certificate from the stream; -showcerts on s_client shows the certificates sent by the server, not a verified chain.

For a smaller output, replace -text with the fields you need:

openssl s_client -servername example.com -connect example.com:443 </dev/null \
  | openssl x509 -noout -dates

openssl s_client -servername example.com -connect example.com:443 </dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

Do not treat successful parsing as successful validation. To verify the endpoint with OpenSSL's configured trust store:

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com -verify_return_error </dev/null

Keep diagnostics visible and inspect the exit status. -servername selects SNI; it does not independently verify the hostname. See OpenSSL s_client.

Use curl for a quick check

curl -vI https://example.com

Depending on its version and TLS backend, curl may show the subject, issuer, and validity dates. Some builds label this section Server certificate; others do not provide identical details. A text filter such as the following is therefore a convenience, not a portable verifier:

curl -vI https://example.com 2>&1 | grep -A8 'Server certificate'

-I requests HTTP headers using HEAD. A server's refusal to handle HEAD is distinct from a TLS failure. Use OpenSSL when you need consistently selectable certificate fields. See curl's TLS trust documentation.

Inventory certificates with Nmap

nmap -p 443 --script ssl-cert example.com

# Example for an authorized internal subnet:
nmap -p 443 --script ssl-cert 192.168.1.0/24

The script reports certificate information such as identity and validity. Scan only systems you administer or have permission to assess. IP-based scans of shared HTTPS servers may see a default certificate rather than every hostname's certificate; inventory named endpoints separately when SNI matters.

For recurring checks, record the target hostname, port, fingerprint, and expiration date. Recheck each entry point after renewal, especially when several servers or load balancers serve the same name.

Common questions

Is -servername always required?

It makes your intended SNI explicit, especially when -connect uses an IP. OpenSSL 1.1.1 and later normally derive SNI from a DNS name supplied to -connect. Use -noservername when deliberately testing a client without SNI.

How do I save the leaf certificate?

openssl s_client -servername example.com -connect example.com:443 </dev/null \
  | openssl x509 -out example.pem
openssl x509 -in example.pem -text -noout

This saves a public certificate, not the server's private key.

What if the port is not 443?

Use the real port in -connect, the curl URL, or Nmap's -p option. For example, https://example.com:8443. Protocols that upgrade with STARTTLS need the appropriate protocol-specific option rather than an ordinary HTTPS probe.