How to recover from the Heartbleed OpenSSL vulnerability

Updated -


If you believe your site may have been impacted through the CVE-2014-0160 OpenSSL security vulnerability (commonly referred to as Heartbleed), the first step is to update OpenSSL on all potentially impacted systems. Red Hat has provided fixes for all impacted products:

All other Red Hat products that include OpenSSL were not affected by this issue, as they included an older version of OpenSSL, which does not expose the exploitable functionality. For products layered on top of RHEL, such as Red Hat Satellite, OpenStack, or OpenShift, follow the steps above for securing RHEL systems. Once you have updated your system, you can utilize Red Hat's Heartbleed Detector to confirm the fix is in place.

Red Hat is not aware of any public exploit being used in the wild for this issue prior to the date of disclosure. However, a number of public exploits were published shortly after the issue was disclosed. These exploits could lead to the disclosure of information handled by applications using OpenSSL, including private keys, session tokens, and data submitted by users, which could include authentication credentials.

Note that several security researchers have now proven that it is possible to retrieve private keys from an nginx server vulnerable to his flaw. It has not yet been proven that private keys can be retrieved from Apache httpd servers. The proven attacks against nginx were successful shortly after a system reboot. This leads to the private key being stored in uninitialized heap memory, thereby making it more feasible to retrieve.

It is recommended that you assess the risk this could pose to your systems, and perform additional remediation as you deem appropriate, for example replacing SSL keys.

Replacing SSL Keys

Now that your system is no longer vulnerable, it is strongly recommended to replace any SSL keys which could have been compromised, as described below.

Self-Signed Certificate

If you are using a self-signed certificate, you can regenerate them using the following steps:

  1. How to create a Certificate Signing Request with a Certificate Authority
  2. How to apply the Certificate Authority signed certificate

CA Generated Certificates

If you received a signed certificate from a CA signing authority, you will need to work with that vendor to generate new certificates.

Updating SSL Certificates in Red Hat Products

Many Red Hat products are configured to use SSL certificates to secure key services. After creating or receiving new certificates and keys, please follow the guides below to update your configuration to utilize new certificates once generated.

Red Hat Enterprise Virtualization

Replacing the SSL certificate used by RHEV Manager for HTTPS connections (RHEV 3.0, 3.1, 3.2, and 3.3)

Red Hat Storage

Red Hat Storage Configuring SSL

Red Hat Satellite

How do I update my Red Hat Network Proxy or Satellite Server SSL keys and certificates?

OpenLDAP server on Red Hat Enterprise Linux with SSL

How to configure OpenLDAP server with SSL/TLS on Red Hat Enterprise Linux 6?

SSL encrypted FTP on Red Hat Enterprise Linux

How to configure vsftpd with SSL/TLS on Red Hat Enterprise Linux

Red Hat Update Infrastructure

Configuring Red Hat Update Appliance SSL Certificates

OpenShift Enterprise

OpenShift SSL Certificates

Red Hat Enterprise Linux OpenStack Platform

OpenStack Configuring TLS/SSL

Configure HTTPD to use SSL

OpenStack Nova Configuring TLS/SSL

OpenStack Glance Configuring TLS/SSL

OpenStack Configuring SSL for Block Storage

OpenStack Testing that SSL certificates are set up correctly

Web Servers

If you are using OpenSSL on a web server, for example using mod_ssl and Apache httpd, then remote attackers may have used this flaw to compromise session tokens and plaintext user credentials stored in memory. Tools allowing attackers to automatically harvest session tokens from servers vulnerable to this flaw are publicly available.

If you are concerned that session tokens and credentials may have been compromised on a web server running OpenSSL, you may wish to perform the following additional remediation steps:

  1. Log out all users on the web server, and clear the session token
    cache. This can usually be performed by restarting the httpd service.
  2. Optional: Reset all user passwords.

Note that this is an invasive change, and it is recommended that you weigh the cost of performing this step against the risk of not performing it.

Additional Steps

Depending on your specific circumstance, you may want to take additional steps. Items such as public internet availability vs intranet could determine how targeted an attack could be. For example, if you are hosting a public website that requires users to log in, you may want to have your users change their passwords.