Guide to OpenSSL Command

Posted on March 25, 2024

OpenSSL is a versatile tool for generating private keys, creating certificate signing requests (CSRs), and managing SSL/TLS certificates. This article will cover how to identify your OpenSSL version, use common OpenSSL commands, and follow best practices for securing your keys and certificates.

Checking Your OpenSSL Version

Identifying Your OpenSSL Version Using OpenSSL Commands

Identifying which version of OpenSSL you are using is an important first step when preparing to generate a private key or CSR. Your version of OpenSSL dictates which cryptographic algorithms can be used when generating keys as well as which protocols are supported. For example, OpenSSL version 1.0.1 was the first version to support TLS 1.1 and TLS 1.2.

Use the command openssl version -a to identify which version of OpenSSL you are running. The -a switch displays complete version information, including:

  • The version number and release date (e.g. OpenSSL 1.0.2g 1 Mar 2016)
  • The options that were built with the library
  • The directory where certificates and private keys are stored (OPENSSLDIR)

Here is an example output from running openssl version -a:

OpenSSL 1.0.2g  1 Mar 2016
built on: reproducible build, date unspecified
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -
D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-
strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-
Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -
OPENSSLDIR: "/usr/lib/ssl"

Knowing your OpenSSL version is important for determining which cryptographic algorithms and protocols are supported when generating keys and CSRs. The output provides key details like the version number, build options, and the default certificate and key storage directory.

Commonly Used OpenSSL Commands

OpenSSL provides many commands for generating private keys, creating CSRs, installing SSL/TLS certificates, and identifying certificate information. Here are some of the most used OpenSSL commands:

  • openssl genrsa: Generates an RSA private key. Example: openssl genrsa -out privatekey.key 2048
  • openssl req: Creates a CSR or self-signed certificate. Example: openssl req -new -key privatekey.key -out csr.csr
  • openssl x509: Shows certificate information, converts formats, and signs CSRs. Example: openssl x509 -in cert.crt -text -noout
  • openssl pkcs12: Converts between PFX, PEM and DER formats. Example: openssl pkcs12 -export -out cert.pfx -inkey privatekey.key -in cert.crt
  • openssl s_client: Establishes a secure connection to a remote server. Example: openssl s_client -connect

These commands let you do important tasks like generating strong private keys, creating CSRs with the needed information, installing and configuring SSL/TLS certificates, and finding issues.

OpenSSL Command Structure and Options

Most OpenSSL commands follow a consistent structure:

openssl command [options] [arguments]
  • command specifies the operation to do, such as genrsa, req, or x509.
  • [options] change the behavior of the command. Options usually start with a hyphen (-) and may have a value.
  • [arguments] give additional information needed by the command, such as input and output file paths.

Some commonly used options include:

  • -in: Specifies the input file path.
  • -out: Specifies the output file path.
  • -keyout: Specifies the path to write the new private key.
  • -pubout: Outputs the public key of a private key or CSR.
  • -text: Prints the content of a certificate in plain text format.
  • -noout: Prevents output of the encoded certificate data.

For example, the command openssl x509 -in cert.crt -text -noout uses the x509 command to show the certificate information in plain text without showing the encoded data.

Learning these OpenSSL command structures and commonly used options will help you effectively use OpenSSL for your SSL/TLS certificate needs.

Generating Private Keys and CSRs Using OpenSSL

Choosing Key Generation Options

When making a private key for your SSL/TLS certificate, you must pick between the RSA and ECDSA key algorithms. RSA is widely supported and suggested for compatibility. You also need to choose a key size of at least 2048 bits for RSA or 256 bits for ECDSA. Bigger key sizes give more security but may affect performance.

Another choice is whether to use a passphrase to encrypt the private key. Using a passphrase adds an extra layer of security, but needs entering it each time the key is used. Passphrases can be helpful if the key may be seen by unauthorized access.

Making Your Private Key Using OpenSSL Commands

To make a 2048-bit RSA private key, use the command:

openssl genrsa -out yourdomain.key 2048

This makes a private key file named yourdomain.key in the PEM format. You can view the raw, encoded contents of the key with:

cat yourdomain.key

Or decode it to view the key details with:

openssl rsa -text -in yourdomain.key -noout

Getting Your Public Key from the Private Key

The made private key file has both the private and public keys. If needed, you can get just the public key using:

openssl rsa -in yourdomain.key -pubout -out yourdomain_public.key

This makes a file named yourdomain_public.key with the public key in PEM format.

Making Your CSR

To make a Certificate Signing Request (CSR) using your private key, use:

openssl req -new -key yourdomain.key -out yourdomain.csr

This asks you to answer questions about your company and domain to include in the CSR. Or, provide all the CSR details in the command using the -subj option:

openssl req -new -key yourdomain.key -out yourdomain.csr \
-subj "/C=US/ST=New York/L=New York/O=Your Company/OU=IT/"

You can also make the private key and CSR together in one command:

openssl req -newkey rsa:2048 -keyout yourdomain.key -out yourdomain.csr

Checking CSR Information

Before sending your CSR to a Certificate Authority (CA), check the information is correct with:

openssl req -text -in yourdomain.csr -noout -verify

This shows the CSR details in plain text. If any information is wrong, you must make a new CSR. Wrong details cannot be changed without making a new CSR due to the digital signature.

By knowing these key generation options and OpenSSL commands, you can make strong private keys and CSRs made for your SSL/TLS certificate needs.

Managing Certificates

Viewing Certificate Information

After you get your SSL/TLS certificate from the certificate authority (CA), you should check that the certificate's details match your private key. Use this command to view the contents of your certificate:

openssl x509 -text -in yourdomain.crt -noout

This shows the certificate information in plain text without the encoded data. Look at the Subject Public Key Info section to see the public key details. Make sure they match the public key in your CSR and private key files.

Verifying Your Keys Match

To check that your certificate's private key, CSR, and the issued certificate all have the same public key, you can extract the public key from each file and generate a hash of it. If the hashes match, the keys are the same.

Use these commands to get the hash of the public key for each file:

openssl pkey -pubout -in yourdomain.key | openssl sha256
openssl req -pubkey -in yourdomain.csr -noout | openssl sha256 
openssl x509 -pubkey -in yourdomain.crt -noout | openssl sha256

Run each command separately to get three hashes. If all the hashes are equal, the public keys match across your private key, CSR, and certificate.

If the hashes don't match, it often means the CSR was made on a different machine than where the certificate is being installed. To fix key mismatches, you can either:

  • Move the private key from the CSR machine to the certificate machine
  • Install the certificate on the machine that has the matching private key
  • Make a new private key and CSR on the machine that will use the certificate

Converting Certificate Formats

By default, OpenSSL makes private keys and CSRs in the PEM format. But you may need to convert them to other formats like PKCS#12 or DER for certain systems.

To convert a PEM certificate and private key into a PKCS#12 (.pfx or .p12) file for transfer:

openssl pkcs12 -export -name "yourdomain-digicert-(expiration date)" \
-out yourdomain.pfx -inkey yourdomain.key -in yourdomain.crt

This combines your yourdomain.key private key and yourdomain.crt certificate into a yourdomain.pfx file. The -name option sets a friendly name that includes the domain and expiration date. You'll be asked to enter an encryption password for the .pfx file.

To convert a .pfx file back to PEM format, use separate commands for the key and certificate:

openssl pkcs12 -in yourdomain.pfx -nocerts -out yourdomain.key -nodes
openssl pkcs12 -in yourdomain.pfx -nokeys -clcerts -out yourdomain.crt

The first command extracts the private key and the second extracts the certificate. The -nodes option removes the private key encryption.

To convert between PEM and DER formats, use the x509 and rsa commands with the -inform and -outform switches:

openssl x509 -inform PEM -in yourdomain.crt -outform DER -out yourdomain.der
openssl rsa -inform PEM -in yourdomain.key -outform DER -out yourdomain_key.der

These commands convert a PEM certificate to DER and a PEM private key to DER. To go from DER back to PEM, just swap the -inform and -outform values.

By using these OpenSSL commands to view, verify, and convert your SSL/TLS certificates and keys, you can properly manage and install them on your servers like Apache Tomcat or IIS.

Here is the rewritten content with the requested changes:

Listing Cipher Suites

Cipher suites are sets of algorithms used to secure network connections with SSL/TLS. They include key exchange, authentication, encryption, and hash algorithms. To see what cipher suites your OpenSSL version supports, use the following command:

openssl ciphers -v

This shows the full names of each supported cipher suite. The names follow a format like:


For example, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 uses:

  • TLS protocol
  • ECDHE key exchange
  • RSA authentication
  • AES-256 encryption in GCM mode
  • SHA384 hash

Knowing these naming pieces can help pick cipher suites that meet your security, compatibility, and performance needs.

Making and Checking Hashes

Hashes are unique, fixed-length digests made from data. They help check the integrity of files and messages. Use OpenSSL commands to make hashes of keys and certificates:

openssl dgst -sha256 yourdomain.key
openssl dgst -sha256 yourdomain.csr 
openssl dgst -sha256 yourdomain.crt

These make SHA-256 hashes of your private key, CSR, and certificate files. You can change sha256 to other hash algorithms like md5, sha1, or sha512.

To check a file's integrity, hash it and compare to a known correct hash value. If they match, the file hasn't changed. This is often used for file downloads to make sure they weren't damaged or changed.

By listing supported cipher suites and making file hashes, you can better secure and check your SSL/TLS setup with OpenSSL.

Debugging and Troubleshooting

Common OpenSSL Issues and Their Solutions

When working with OpenSSL to generate keys, create CSRs, and install SSL/TLS certificates, you may run into some common problems. Here are a few issues and how to troubleshoot them:

  • Certificate installation and configuration issues: Double check that the certificate file paths are correct in your web server configuration. Make sure the certificate and private key are in the proper formats (PEM or PKCS#12) required by your server.

  • Private key and certificate mismatches: Verify that the private key used to generate the CSR matches the one used during certificate installation. Compare the hashes of the public keys in the private key, CSR, and certificate files. If they don't match, regenerate the CSR with the correct private key.

  • File permission and ownership problems: Check that the private key and certificate files have the correct permissions and ownership set for your web server process to read them. For example, on Linux, you may need to set permissions with chmod 400 yourdomain.key and ownership with chown www-data:www-data yourdomain.key.

  • OpenSSL command errors: If you get errors running OpenSSL commands, double check the syntax, options, and file paths. Make sure you're using the correct commands for your OpenSSL version and the files are in the right formats.

Identifying TLS Versions and Configurations

It's important to check that your OpenSSL and web server are set up to use the latest TLS versions and strong cipher suites. Here's how to check:

  1. Check your OpenSSL TLS version support: Use the s_client command to see the TLS version used for a connection:

    openssl s_client -connect -tls1_2

    Replace with your domain name. The -tls1_2 option tests a TLS 1.2 connection. You can change it to -tls1, -tls1_1, or -tls1_3 to test other versions. A successful connection means that TLS version is supported.

  2. Verify your web server TLS configuration: Check your web server's SSL/TLS settings to make sure it's set up to use TLS 1.2 or 1.3 and not old versions like SSL 3.0 or TLS 1.0. For example, in Apache you might see settings like:

    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5

    This turns off SSL 3.0, TLS 1.0, and TLS 1.1 while enabling high-strength cipher suites. Check your web server's documentation for the proper TLS configuration settings.

  3. Use SSL/TLS testing tools: Online tools like the SSL Labs Server Test can check your server's SSL/TLS setup and find issues with the certificate, protocol versions, or cipher suites.

By finding and fixing these common OpenSSL issues and making sure you have a secure TLS setup, you can better debug and troubleshoot your SSL/TLS configuration for your domains.

Best Practices

Securely Managing Private Keys and Certificates

Private keys are the foundation of your SSL/TLS security. It's important to generate, store, and protect them properly. Here are some best practices:

  • Generate private keys with at least 2048-bit RSA or 256-bit ECDSA for strong security
  • Use a passphrase to encrypt the private key file for an extra layer of protection
  • Store private keys in a secure location with strict access controls, such as a locked safe or an encrypted hardware security module (HSM)
  • Limit access to private keys to only those administrators who absolutely need it
  • Never share private keys over insecure channels like email or messaging
  • Regularly rotate and update private keys, especially if there's any chance of compromise

SSL/TLS certificates also need to be carefully managed and deployed. Some guidelines include:

  • Use a reliable and trusted certificate authority (CA) to issue your certificates
  • Choose the right type of certificate for your needs, such as single-domain, multi-domain, or wildcard
  • Securely deliver the certificate signing request (CSR) to the CA, such as through an encrypted web form or email
  • Store certificates in a protected location, with limited access for administrators
  • Properly install and configure certificates on your web servers, load balancers, and other SSL/TLS endpoints
  • Keep track of certificate expiration dates and renew them before they expire to avoid downtime
  • Replace certificates if the private key is compromised or if the certificate needs to be revoked for any reason

Keeping OpenSSL Up to Date

Using the latest version of OpenSSL is important for getting the newest security fixes, protocol and algorithm support, and features. Older versions can have known vulnerabilities that attackers can exploit.

Check your OpenSSL version with openssl version and compare it to the latest releases on the OpenSSL website. If you're not on the newest version, update it as soon as possible.

The update process depends on your operating system and environment:

  • On Linux, use your package manager to install the latest OpenSSL version. For example, on Ubuntu or Debian:
    sudo apt update
    sudo apt install openssl
  • On Windows, download the latest OpenSSL installer or binaries from the official site or a trusted third-party provider. Replace your old OpenSSL directory with the new version.
  • For programming languages and frameworks like Python, Ruby, or Node.js, update the OpenSSL library that they use. This may mean updating the language/framework itself or any SSL/TLS wrapper libraries.
  • On web servers like Apache or Nginx, update the server version or OpenSSL modules to get the latest version. Check the server documentation for specific update instructions.

After updating OpenSSL, be sure to test your SSL/TLS configuration and certificates to make sure everything is still working properly. Tools like SSL Labs can help find any issues.

By following these best practices for securely managing keys and certificates and keeping OpenSSL up to date, you can better protect your SSL/TLS setup and the data of your users.

Monitoring SSL Certificates

Monitoring your SSL certificates is a crucial part of maintaining a secure and reliable website. Expired or misconfigured SSL certificates can lead to security vulnerabilities and a poor user experience. Uptimia offers an SSL Certificate Monitoring service that helps you keep track of your certificates' health and validity. With Uptimia, you can receive alerts when a certificate is nearing expiration or has any technical issues, such as mismatched domain names, weak encryption algorithms, or invalid certificate chains. By proactively monitoring your SSL certificates with Uptimia, you can feel safe that your website remains secure and accessible to your users.

Key Takeaways

  • Use the command openssl version -a to identify your OpenSSL version, build options, and default certificate and key storage directory
  • Common OpenSSL commands include genrsa for generating private keys, req for creating CSRs, x509 for viewing and converting certificates, pkcs12 for converting formats, and s_client for testing secure connections
  • When generating private keys, choose between RSA (recommended) and ECDSA algorithms, use a key size of at least 2048 bits for RSA or 256 bits for ECDSA, and consider using a passphrase for added security
  • Use OpenSSL commands to view certificate information, verify key matches, convert between PEM, PKCS#12, and DER formats, list supported cipher suites, and create file hashes
  • Follow best practices like generating strong private keys, using a trusted CA, securely storing and managing keys and certificates, and keeping OpenSSL up to date to protect your SSL/TLS setup