Skip to main content

6 OpenSSL command options that every sysadmin should know

Look beyond generating certificate signing requests and see how OpenSSL commands can display practical information about certificates.
6 OpenSSL command options every sysadmin should know
Image by Uwe Baumann from Pixabay

Transport layer security (TLS) is an important part of any security strategy, and applications beyond web servers increasingly take advantage of the protections offered by public-key cryptography. The OpenSSL toolkit is the fundamental utility that any systems administrator must know if they are responsible for maintaining TLS-protected applications. In this article, I demonstrate some of the most common commands that I use daily. While many articles focus on the generation of certificate signing requests (CSRs) or self-signed certificates, this article will spend some time reviewing OpenSSL commands and one-liners beyond the certificate generation process.

[ You might also enjoy: Making CA certificates available to Linux command-line tools ]

Checking certificate validity

One of the most common troubleshooting steps that you’ll take is checking the basic validity of a certificate chain sent by a server, which can be accomplished by the openssl s_client command. The example below shows a successfully verified certificate chain sent by a server ( after a connection on port 443. The -brief flag excludes some of the more verbose output that OpenSSL would normally display. Note that the "Verification" is output as "OK."

By default, openssl s_client will read from standard input for data to send to the remote server. Appending an echo to the one-liner sends a newline and immediately terminates the connection. Without this, you would need to press Ctrl+C to quit the connection.

$ echo | openssl s_client -connect -brief
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256
Peer certificate: C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU = Information Technology, CN = *
Hash used: SHA256
Signature type: RSA
Verification: OK
Supported Elliptic Curve Point Formats: uncompressed
Server Temp Key: ECDH, P-256, 256 bits

Contrast the above output with the example below. In this output, you can clearly see that the verification failed with an error: “self-signed certificate.”

$ echo | openssl s_client -connect -brief
depth=0 C = US, ST = California, L = San Francisco, O = BadSSL, CN = *
verify error:num=18:self signed certificate
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256
Peer certificate: C = US, ST = California, L = San Francisco, O = BadSSL, CN = *
Hash used: SHA512
Signature type: RSA
Verification error: self signed certificate
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: ECDH, P-256, 256 bits

Determining when a certificate expires

Every sysadmin has experienced the embarrassment that follows from allowing a certificate for a public-facing website to expire. There are plenty of monitoring tools to keep an eye on this and ensure that it doesn’t happen to you, but what if you just want to quickly check a certificate’s expiration date from the command line? OpenSSL has you covered.

Checking the expiration date of a certificate involves a one-liner composed of two OpenSSL commands: s_client and x509. You already saw how s_client establishes a connection to a server in the previous example. By piping the output into x509, you can obtain the certificate’s validity period by using the -dates flag. Below are examples for both a valid and an expired certificate.

# A valid certificate that hasn’t expired yet
$ echo | openssl s_client -connect 2>/dev/null | openssl x509 -noout -dates
notBefore=Jul  9 00:00:00 2019 GMT
notAfter=Aug  2 12:00:00 2021 GMT

# A certificate that expired in 2015
$ echo | openssl s_client -connect 2>/dev/null | openssl x509 -noout -dates
notBefore=Apr  9 00:00:00 2015 GMT
notAfter=Apr 12 23:59:59 2015 GMT

Checking certificate extensions

X509 extensions allow for additional fields to be added to a certificate. One of the most common is the subject alternative name (SAN). The SAN of a certificate allows multiple values (e.g., multiple FQDNs) to be associated with a single certificate. The SAN is even used when there aren’t multiple values because the use of a certificate’s common name for verification is deprecated.

Similar to the previous one-liner, piping output between multiple OpenSSL commands makes it easy to inspect specific certificate extensions and allows you to view the SANs associated with a certificate:

$  echo | openssl s_client -connect 2>/dev/null | openssl x509 -noout -ext subjectAltName
X509v3 Subject Alternative Name:

Another common set of extensions include the basic constraints and key usage of a certificate. Specifically, you might want to check if a certificate is allowed to be used as a certificate authority. Again, this can be done in the same way that you can check for a SAN:

$  openssl x509 -ext basicConstraints,keyUsage -noout -in /usr/share/ca-certificates/mozilla/VeriSign_Universal_Root_Certification_Authority.crt
X509v3 Basic Constraints: critical
X509v3 Key Usage: critical
    Certificate Sign, CRL Sign

Checking deprecated TLS ciphers or versions

Excellent web-based tools, such as Qualys SSL Lab, exist to provide you with a full report on the security of your TLS configuration. This includes alerting you to the use of insecure cipher suites and other configuration parameters that may weaken the security posture of a TLS-protected resource. However, you might just want to run a quick test from the command line, and OpenSSL makes this easy.

First, you can list the supported ciphers for a particular SSL/TLS version using the openssl ciphers command. Below, you can see that I have listed out the supported ciphers for TLS 1.3. The -s flag tells the ciphers command to only print those ciphers supported by the specified TLS version (-tls1_3):

$ openssl ciphers -s -tls1_3

The s_client command can then be used to test different TLS versions and cipher suites. The website is a useful repository of information about the strength of various cipher suites. As an example, attempting to use the weak TLS_PSK_WITH_AES_128_CBC_SHA suite against a server that doesn’t support it will result in an error:

openssl s_client -connect -cipher PSK-AES128-CBC-SHA -quiet -no_tls1_3
139963477378368:error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available:../ssl/statem/statem_clnt.c:3794:No ciphers enabled for max supported SSL/TLS version

Similarly, you can specify the version of the TLS protocol used in the connection. The example below shows that TLS 1.1 isn’t supported by the server. Be sure to review the manpage to see a full list of options.

$ openssl s_client -connect -tls1_1 -quiet
139890998576448:error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available:../ssl/statem/statem_clnt.c:1112:

Inspecting a certificate

I’ve covered looking at particular parts of a certificate, such as validity dates or X509 extensions. Sometimes, you just want to see everything about a specific certificate. The X509 utility can be used with the -noout (to suppress printing the encoded certificate), -text (to print out text information about the certificate), and the -in (to specify the input file) flags to print out everything you’d want to know about a particular certificate. The example below uses a certificate file on my local system, but you could just as easily pipe the output from openssl s_client, as seen in the previous examples.

$ openssl x509 -text -noout -in /usr/share/ca-certificates/mozilla/VeriSign_Universal_Root_Certification_Authority.crt
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2008 VeriSign, Inc. - For authorized use only", CN = VeriSign Universal Root Certification Authority
            Not Before: Apr  2 00:00:00 2008 GMT
            Not After : Dec  1 23:59:59 2037 GMT
        Subject: C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2008 VeriSign, Inc. - For authorized use only", CN = VeriSign Universal Root Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier: 
    Signature Algorithm: sha256WithRSAEncryption

Generating some random data

At this point, you’ve become comfortable with connecting to servers and inspecting certificates. I’ll end with one final trick that frequently comes in handy for me. The openssl rand command can be used to generate pseudo-random bytes. The -base64 flag will base64 encode the output, providing you with a random string that can be used as a password or for other applications that require a random string. Just make sure that the number of bytes is divisible by three to avoid padding.

$  openssl rand -base64 9

[ Get this free book from Red Hat and O'Reilly - Kubernetes Operators: Automating the Container Orchestration Platform. ] 

Wrap up

In this article, you learned some basic OpenSSL commands that can make your daily life as a systems administrator easier. OpenSSL is a very powerful suite of tools (and software library), and this article only touched the surface of its functionality. However, these commands are both a good starting point for developing further knowledge of OpenSSL and a useful set of tools to have in the toolbox of any sysadmin who regularly works with TLS-protected servers.

Check out these related articles on Enable Sysadmin

Author’s photo

Anthony Critelli

Anthony Critelli is a Linux systems engineer with interests in automation, containerization, tracing, and performance. He started his professional career as a network engineer and eventually made the switch to the Linux systems side of IT. He holds a B.S. and an M.S. More about me

Free Event: Red Hat Summit 2021 Virtual Experience

Join Red Hat Summit Virtual Experience for live demos, keynotes, and technical
sessions from experts around the globe—happening April 27–28 and June 15–16.

Related Content