Many sites reusing Heartbleed-compromised private keys

Many sites reusing Heartbleed-compromised private keys

Summary: Heartbleed has forced many to revoke and reissue TLS/SSL certificates, but more than seven percent have been reissued with the same keys.

TOPICS: Security

Since the Heartbleed vulnerability in OpenSSL was announced on April 7, more than 30,000 TLS/SSL certificates have been revoked and reissued with the same keys, missing the whole point of the exercise.

That number comes from Netcraft's SSL survey, an ongoing research project studying TLS/SSL sites across the Internet.

Heartbleed allowed an attacker to determine an OpenSSL-based server's private keys, thus removing any data protection and allowing an attacker to masquerade as the server. This meant that, aside from updating their OpenSSL installation, sites had to revoke their old certificates and reissue new ones.

According to Netcraft's survey (see Netcraft's Euler diagram below), 43 percent of sites have reissued their certificates since the appearance of Heartbleed. Seven percent of those have reissued them with the same private key. Only 14 percent have revoked and reissued with new keys, which is the full set of tasks necessary to prevent attack.

Overall, 20 percent have revoked their old certificate, a few without reissuing. Finally, five percent have revoked and reissued, but used the same keys as the earlier certificate.


Most certificate authorities are not automatically checking for key reuse. Tools, such as Netcraft's, can be used to determine if the problem exists on a particular site.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • "reissued them with the same private key"

    poor phrasing.

    To my knowledge it is impossible to "issue" a certificate without changing the private key...

    If you use the same private key you are also using the same public key.

    Now I can see that happening - mostly due to having to wait for a re-issued certificate... that hasn't arrived yet. (had that happen in the past - the organization issuing the certificates took a week to process the request, and that was without problems of identity checking).
    • sure you can

      New certificate with new serial #, same keys. Why is this impossible?
      Larry Seltzer
      • The generation of the certificate involves generating the public and..

        private keys.

        Otherwise you are not generating a certificate. Just signing one - and that is reusing a certificate.
        • They didn't generate a new CSR and Private key

          I think the problem is they are getting thier certificates resisued using the same old CSR (Certificate Signing Request) which was generatesd using the old private key.

          Therefore they will get a new cert that was generated using the compomised private key and thus sill be vulnerable.

          Most SSL sites will warn against using the same old CSR for renewals and reissues but will still let you do it.
          • That would even be more stupid

            without a new CSR, you simply re-issuing the exact same certificate.

            It is trivial to generate a new CSR using the existing (possibly compromised) private key).

            This is what this article alludes to. Perfect possibe to generate a CSR using the exact same private key, which indeed is not a very smart thing to do, as that private key might have been compromised by the heartbleed vulnerability.
          • To further clarify

            This is what the openssl website has to say about private /public key:

            "Keys are the basis of public key algorithms and PKI. Keys usually
            come in pairs, with one half being the public key and the other half
            being the private key. With OpenSSL, the private key contains the
            public key information as well, so a public key doesn't need to be
            generated separately.


            In general there are four steps to get a certificate on to your webserver:

            1) Generate the private key openssl genrsa -out privkey.pem 2048
            2) Generate the CSR openssl req -new -key privkey.pem -out cert.csr
            3) Send the cert.csr in step 2 to your CA
            4) configure your webserver to use privkey.pem from step 1 as your private key file and the certificate obtained from your CA in step 3 as your certificate file

            step 2 will prompt for additional information such as Country, City, Province, email, common name and company name, or if using openssl.conf this can be configured in that file.

            Now since I had nothing better to do, I actually run 3 methods of re-issuing the certifcate in light of the heartbleed vulnerability.

            I used an ubuntu 12.04 LTS server with an existing certificate, I obtained the public key of the certifcate and then re-issued the certifcate using the steps noted above but with certain steps being omitted.

            A) ran all required steps except 1. This leads to the issued certificate having the exact public key (and private key obviously) as the Original certificate

            B) ran all required steps except 1+2 which leads to the exact same result as method A

            C) ran all required steps except 2 This one leads to the website being unable to load as there is a key mismatch, I did change the private key in step 1 but didn't create a new CSR based upon that private key, so the public key remains the same. Apache will note the following in the log:

            [Sat May 10 13:32:29 2014] [error] Unable to configure RSA server private key
            [Sat May 10 13:32:29 2014] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

            Any admin that applied either A or B will be amongst those 7% this article speaks of, whilst the admin that applied C might have saved him or herself from the embarrasment as the website won't load. If the admin still had the Original key file and changed the webserver to use that, he or she would be amongst the 7%, if the Original keyfile wasn't available anymore, the admin would be forced to follow all the steps in order to get the website to load.

            If I read the diagram correctly, the state and expertise of the server admins leaves much to be desired. Only 43% actually bothered to replace the certificate, and a significant percentage didn't do it correctly, also because the percentage that actually revoked the old certificate is only 20%
          • Sounds about right...

            ...given the majority of server admins I've known.
          • Exactly

            /agree, Nice Job
  • Euler Diagram?

    What's an Euler diagram? How does it differ from a Venn diagram. The diagram in the article looks like a Venn diagram.
    • close, but not the same

      I had the same thought. I used "Euler" because that's what Netcraft used.

      From Wikipedia ( "Venn diagrams are a more restrictive form of Euler diagrams. A Venn diagram must contain all 2n logically possible zones of overlap between its n curves, representing all combinations of inclusion/exclusion of its constituent sets. Regions not part of the set are indicated by coloring them black, in contrast to Euler diagrams, where membership in the set is indicated by overlap as well as color. When the number of sets grows beyond 3 a Venn diagram becomes visually complex, especially compared to the corresponding Euler diagram."

      There, clear as mud, right?
      Larry Seltzer
  • Liability?

    This is probably not the best place to ask this question, but here it is anyway. If a site assures us that they have corrected their vulnerability, yet simple reuses the old key, are they liable for any resulting losses?
  • Good Information

    Thanks for the article, Larry. I guess the take-away from this is that Heartland is still a threat even for many of the websites that claim to have addressed it. And there are all those who have yet to do anything.