Not all Heartbleed vulnerability checkers are equal. DigiCert is here to help!

While the Heartbleed OpenSSL vulnerability is not a flaw in the SSL or TLS protocols, it does allow an attacker to secretly access sensitive information that is otherwise protected by the SSL and TLS protocols.

In spite of good intentions, unfortunately, some of the publicly available Heartbleed checkers are themselves flawed. In fact, in certain situations, they can unintentionally return false negative results or even take actions that further compromise your network.

In an effort to help everyone be safe from the Heartbleed vulnerability, DigiCert has created Discovery, an SSL vulnerability tool, which safely and accurately examines all of your external AND internal SSL Certificates and SSL Termination Endpoints for potential vulnerabilities, including the Heartbleed Bug.

Heartbleed 'Gotchas'

We’ve listed here, the six most frequent ‘gotchas’ that are tripping people up as they work to identify and address the Heartbleed vulnerability.

Exposing Network Data:

  • The quick way for a checker to determine if you are vulnerable is to actually attempt to exploit the Heartbleed vulnerability. Most checkers do this by doing a partial SSL handshake and then asking for a large amount of data to be returned, all before the session becomes encrypted. As a result, the checker downloads kilobytes of real data from your server's memory. By accessing this data, these checkers are actually revealing your data to any attackers that are monitoring the exchange. In addition, if the checker asks for a smaller amount of data to be returned, the OpenSSL server may not respond immediately, causing the checker to report a false negative. These checkers are telling you that you are safe when you are not!
  • Discovery performs a complete SSL handshake before any Heartbleed test is started. This ensures the test is performed under full SSL security and encryption. This test only asks for a single byte of extra data from your server. In fact, the single byte of extra data that is returned is part of the Heartbeat request padding so even this single byte of data has no information about your server. This ensures a reliable and safe procedure to test whether you are vulnerable to Heartbleed without exposing any of the sensitive data on your server or network.

Reusing the same CSR when re-keying SSL Certificates:

  • When re-keying your SSL Certificates, be careful not to accidentally re-submit your old CSRs. Accidently reusing your old CSR results in a certificate that uses the same old, potentially compromised private key.
  • Create a new CSR using the instructions at

Limiting to External Scans:

  • Most, if not all, Heartbleed Bug checkers are limited to scanning your external servers for the vulnerability, leaving the vulnerability status of your internal network unknown.
  • You can run the Discovery on both external and internal-facing servers, securing your entire environment from the Heartbleed Bug.

Only Checking NotBefore Dates:

  • Some Heartbleed checkers look at the NotBefore field (the beginning date) of an SSL Certificate to determine if it was issued before or after the Heartbleed fix was issued. This approach has two major problems, namely, a site could have a new certificate, but if it was installed before patching the OpenSSL installation, it is subject to the same vulnerabilities as the previous certificate. Also, very few SSL Certificates that have been re-keyed will display a new NotBefore date.
  • Discovery checks for the actual Heartbleed vulnerability and does not look at the NotBefore date, eliminating this potential for false positive results.

Static linking of OpenSSL versus dynamic linking:

  • If you have a version of OpenSSL that is compiled into your server software, you can still be vulnerable even if you have updated your OpenSSL library, as some systems may still be hard coded to out of date versions of OpenSSL or simply be referencing cached memory.
  • After patching your system and software, be sure to restart your patched software, as needed, in order to refresh your memory and clear your cache. Make sure to retest to ensure the vulnerability has been resolved.

Changing Passwords before Resolving the Heartbleed Vulnerability:

  • You need to have your users change their passwords AFTER OpenSSL has been patched, systems have been verified as not vulnerable, certificates have been rekeyed, reissued and installed, and the old certificates have been revoked. If these steps were followed out of order, or if passwords were reset before all of these steps were completed, the passwords may still have been exposed and need to be changed again.
  • Change passwords after you are no longer vulnerable to the Heartbleed Bug.

DigiCert Heartbleed Checkers

Single Domain Checker:

If you would like to check a single external domain enter the URL into the SSL Checker at

Internal/External Multiple Domain Checker:

For more robust testing across both your internal and external systems to determine if you are vulnerable to the Heartbleed Bug, use Discovery Discovery.

To learn more about the six steps to secure yourself from the Heartbleed Bug, visit