OpenSSL essentials: Working with SSL Certificate, Private Key and CSR

  Security, SSL Certificate
openssl ssl csr Certificates, Private Keys and CSRs ubuntu redhat debian centos

Using OpenSSL to generate SSL certificates, private keys and certificate signing requests (CSRs) is an essential skill for any system administrator or security professional. This comprehensive, step-by-step guide will teach you how to use the basic OpenSSL commands to:

Step 1 – Generate a Private Key

The first step is to generate a private key, which will be used later to create the CSR and public key for the SSL certificate.

To generate a 2048-bit RSA private key:

$ openssl genrsa -out private.key 2048

This will create a file called ‘private.key’ that contains the private key. Make sure to protect this file and do not share it publicly.

Some key things to know about private keys:

  • The private key is used to digitally sign the CSR and public key later on.
  • The private key must be kept secret and secured. If compromised, any certificate created with it can be used by attackers.
  • For better security, the key size should be at least 2048 bits. 4096 bits is recommended for stronger security.

Step 2 – Create a CSR (Certificate Signing Request)

Now that we have a private key, we can generate a CSR or certificate signing request. This is sent to the Certificate Authority (CA) to request a public key certificate.

To generate a CSR:

$ openssl req -new -key private.key -out csr.pem

This will prompt you to enter identifying information that will be included in the CSR such as Country Name, Organization Name etc.

Some things to know about CSRs:

  • The CSR contains information about your company and public key.
  • The CSR is digitally signed with your private key to prove you own it.
  • The CA will use the CSR to create the SSL certificate.

Step 3 – Generate a Self-Signed Certificate

Typically, the CSR is sent to a trusted CA like Comodo, Digicert, etc. to sign and generate the SSL certificate.

For testing purposes, we can create a self-signed certificate which is signed by itself rather than a CA.

To generate a self-signed cert:

$ openssl req -new -x509 -key private.key -out self-signed.crt -days 365

This creates a self-signed certificate called ‘self-signed.crt’ valid for 365 days.

Some points on self-signed certificates:

  • Should only be used for testing, not production sites.
  • Will show security warnings in browsers as not signed by a trusted CA.
  • Does not provide any guarantees about identity of the website.

Step 4 – Generate a CSR and Private Key in One Command

In Step 1 and 2 we generated the private key and CSR separately.

OpenSSL can also generate them in one go:

$ openssl req -newkey rsa:2048 -nodes -keyout private.key -out csr.pem

This generates a 2048 bit RSA private key and CSR saving them to the private.key and csr.pem files respectively.

The -nodes parameter tells OpenSSL to store the private key without password protection.

Step 5 – Generate a PKCS#12 Certificate (.pfx .p12)

In some cases, you may need the SSL certificate and private key to be stored together in a PKCS#12 or .pfx file.

This .pfx file can be directly imported into services like IIS on Windows.

To generate a .pfx file:

$ openssl pkcs12 -export -out public_key.pfx -inkey private.key -in public.crt

Where:

  • public_key.pfx is the output .pfx file
  • private.key is the associated private key
  • public.crt is the SSL certificate

When running this, OpenSSL will prompt you to set a password for protecting the .pfx file.

Step 6 – Verify a Certificate Signing Request (CSR)

Once you have generated a CSR, it’s good practice to verify it before submitting it to the CA.

To verify a CSR:

$ openssl req -text -noout -verify -in csr.pem

This parses the CSR, prints out its details in text format, and verifies:

  • It is a properly formatted CSR
  • It has been digitally signed with the associated private key.

This helps catch any errors with the CSR generation before sending it off to a CA.

Step 7 – Verify an SSL Certificate

Once you have obtained an SSL certificate from a CA, you should always verify it before installing on a server.

To verify a certificate:

$ openssl x509 -in public.crt -text -noout

This will print out all the certificate details in text and you can review the following:

  • Issued to – Common name matches your domain
  • Issued by – Reputable CA like Comodo, Digicert etc.
  • Valid from and Expiry date – Certificate is currently valid
  • Signature/Fingerprint – Signature uses secure hash like SHA-256

Verifying these details is important to ensure you have a valid certificate from a trusted CA.

Step 8 – Check a Certificate Signing Request (CSR) and Private Key Match

When submitting a CSR to a CA, you send only the CSR itself and keep the private key private.

But how can you verify that the CSR and private key match when you get back the signed certificate?

OpenSSL provides a way to check that:

$ openssl rsa -noout -modulus -in private.key | openssl md5
$ openssl x509 -noout -modulus -in public.crt | openssl md5

This generates an MD5 hash of the modulus of both the private key and certificate. If the hashes match, it proves the CSR and certificate correspond to the same private key.

Always run this check before installing the SSL certificate for better security.

Step 9 – Check an SSL Certificate is Trusted

After installing an SSL certificate, you should validate that it is trusted by major browsers and operating systems.

This can be done using the SSL test from SSL Labs:

https://www.ssllabs.com/ssltest/analyze.html

Submit your domain and it will analyze the SSL certificate, check trust paths and provide a letter grade on how trusted it is.

The certificate should show as trusted on all major browsers like IE, Chrome, Firefox etc.

Step 10 – Revoke an SSL Certificate

If your private key is compromised, or you need to revoke a certificate for any reason, this is done by contacting the issuing CA.

The CA will have a certificate revocation process that will allow you to request revocation of the certificate.

Once revoked, clients will fail to validate the certificate and show warnings if it is still used on a website.

  • Browsers like Chrome and Firefox check the revocation status of certificates before trusting them.
  • Make sure to replace the revoked cert with a new one to avoid impact to your website.

Step 11 – Generate Wildcard SSL Certificate CSR

A wildcard SSL certificate secures unlimited subdomains on a single certificate.

For example, *.example.com will secure www.example.com, mail.example.com etc.

To generate a wildcard CSR:

$ openssl req -newkey rsa:2048 -nodes -keyout private.key -out csr.pem -subj "/CN=*.example.com"

The key portion is specifying CN=*.example.com in the subject to request a wildcard domain.

Some key facts about wildcard certificates:

  • Supports unlimited subdomains on a single cert.
  • More expensive than individual certs but cost effective for managing multiple subdomains.
  • Comodo and Digicert have good wildcard options trusted by all browsers.

Step 12 – Create a Multi-Domain (SAN) Certificate

Multi-domain or SAN certificates secure multiple domains on a single certificate.

For example, a SAN cert can secure example.com and www.example.com together.

To generate a SAN CSR:

$ openssl req -newkey rsa:2048 -nodes -keyout private.key -out csr.pem -subj "/" -reqexts SAN  -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))

This uses the OpenSSL config file to specify the SAN details.

Some key facts about SAN certificates:

  • Can secure up to 100 domains on a single certificate.
  • More flexible than wildcards for securing multiple specific domains.
  • Supported on all major browsers and platforms.
  • Cost effective for managing multiple domains.

Step 13 – Create Self-Signed Certificates for Internal Systems

Self-signed certificates can be useful for securing internal communications between servers, systems and services within an organization.

For example, securing traffic between a load balancer and web servers; or between internal microservices.

Here is how to generate a self-signed certificate for internal use:

$ openssl req -newkey rsa:2048 -nodes -keyout private.key -x509 -days 365 -out self-signed.crt

And some key points on using self-signed certs internally:

  • Should only be used within internal networks, not for public internet traffic.
  • Provides encryption and security without need for external CAs.
  • Much more cost effective than commercial certs for large number of internal servers.
  • Can be generated programmatically and auto-rotated as needed.

Step 14 – Use OpenSSL to Test SSL Connections

OpenSSL can test SSL connections to check for valid certs, accepted protocol versions, supported ciphers etc.

To test basic SSL connectivity to a server:

$ openssl s_client -connect example.com:443

This will do a TLS handshake with the server and output details like:

  • Certificate details
  • SSL/TLS protocol version
  • Supported ciphers
  • Session information

s_client is useful for debugging SSL related issues with a server or application.

Step 15 – Use OpenSSL to Benchmark SSL Encryption

OpenSSL includes a benchmarking tool to test encryption speed of algorithms like AES, SHA256 etc.

Basic benchmarking command:

$ openssl speed

This tests default algorithms. To test specific ones:

$ openssl speed -evp aes-128-cbc aes-256-cbc

Sample output:

aes-128-cbc     14768.94k   14678.37k   14672.28k   
aes-256-cbc     10528.08k   10506.25k   10475.97k
  • Useful for comparing hardware performance for SSL encryption.
  • Helps determine most optimal ciphers to support.
  • Make sure to test on production hardware for accurate benchmarks.

Conclusion

That covers the core essentials of using OpenSSL for working with SSL certificates and keys.

The key takeaways are:

  • Use genrsa and req commands to generate private keys and CSRs.
  • Understand different types of certs like self-signed vs CA signed.
  • Validate certificates before installing on production servers.
  • Use tools like s_client and speed for debugging and benchmarking.

OpenSSL is a powerful toolkit that every security professional should feel comfortable using. Master these basics and you’ll be ready to securely implement SSL in your infrastructure.

LEAVE A COMMENT