Heartbleed and SSL Certificates

We have spoken to our technical support teams from all of our SSL vendors in regards to this issue and if your server runs the version of OpenSSL that is being affected by this bug (OpenSSL 1.0.1 through 1.0.1f), there are potential vulnerabilities. The first step is to have your servers patched with the new version of OpenSSL (1.0.1g) released on April 7th, 2014. As a precaution we suggest that you re-issue the SSL. Re-issuing the SSL will have the server administrators generate a new private key on their client’s servers. Please note that re-issuing a certificate will deactivate the old one. However, if you would like your certificate’s serial number added to the CRL (Certificate Revocation List), you can contact the vendor and have the old certificate manually revoked.

Below you will find a list of URLs to the portals that will allow you to re-issue your clients’ certificates:

How to use the portals

  1. Enter the domain or supplier id and the contact email address on the order;
  2. The vendor will then send an email to the contact email address where your clients will see a link that will allow them to paste the new CSR;
  3. Once the information is submitted to the vendor, they will re-issue the certificate. Please note that this make take longer than usual due to this OpenSSL bug.

 

Comodo and Trustwave

Please send an email to help@opensrs.com with the new CSR and the domain or supplier id to be reissued.

If you have any additional questions, please contact OpenSRS Support at help@opensrs.com

10 thoughts on “Heartbleed and SSL Certificates

  1. I’ve read that GeoTrust is allowing for certs to be re-issued at no cost, so long as the cert details are not changed.

    Do you know if any other cert authorities are following suit, to provide new keys at no added cost?

    BTW: Do you think that wider adoption of IPv6 have negated this vulnerability?

  2. I’ve read that GeoTrust is allowing for certs to be re-issued at no cost, so long as the cert details are not changed. Thawte and Symantec also allow for a free “Revoke and Replace” over the lifetime of the cert – in order to get new keys at no added cost

    BTW: Do you think that wider adoption of IPv6 could have negated this vulnerability?

  3. Hi JoFergus,

    Please open a ticket with support (help@opensrs.com) if you need information on re-issuing certificates from additional providers.

    The vulnerability was related to a bug in the OpenSSL software.

  4. Are there any plans to allow resellers to use Comodo web interfaces that are available to clients who purchase directly from them?

  5. Are there any plans to allow resellers to use Comodo web interfaces that are available to clients who purchase directly from them?

  6. Hi JoFergus,

    IPv6 wouldn’t of done anything to mitigate this attack. The vulnerability, as Mike stated, exists in the OpenSSL software. More specifically, a missing bounds check allows an attacker to, in simple terms, ask OpenSSL to send him information stored in RAM that the attacker shouldn’t of been able to access to begin with. For a more detailed (but still high level) overview of the attack, check out: http://www.youtube.com/watch?v=hTK0pywfmDE

  7. Thanks for the vid. I saw that at the Vimeo blog when things first started hitting the fan. Great to see Vimeo being open and communicative on the subject So yeah, I have a general understanding of the vulnerability in the SSL model, where OpenSSL was used.

    The point remains…

    I’m still wondering if the use of IPsec (in IPV6) would have made the need for SSL redundant though. ie Can the transport-layer protocol be extended through to provide authentication at the application level – which would negate the need for SSL to begin with?

  8. Thanks for the vid. I saw that at the Vimeo blog when things first started hitting the fan. Great to see Vimeo being open and communicative on the subject So yeah, I have a general understanding of the vulnerability in the SSL model, where OpenSSL was used.

    The point remains…

    I’m still wondering if the use of IPsec (in IPV6) would have made the need for SSL redundant though. ie Can the transport-layer protocol be extended through to provide authentication at the application level – which would negate the need for SSL to begin with?

  9. Yes your right, IPSec is mandatory in the IPv6 framework (I didn’t know to be honest. A day where I learn something is always a good day)

    http://www.sans.org/reading-room/whitepapers/protocols/security-features-ipv6-380?show=security-features-ipv6-380&cat=protocols

    That being said, I’m not sure if IPv6 will entirely replace SSL certificates. Quoted from the above-referenced document:

    “Due to export laws, the strength of the encryption algorithms to be used to
    ensure global interoperability is limited.”

  10. The export regs. around encryption strength is an interesting angle to research further. Thanks for pointing that out.;-)

    So this all begs the question…What’s the holdup on IPv6?
    Some people say that it’s just the Telco’s and CableCo’s who are reluctant to incur costs from upgrading the ‘last mile” to consumers.

    An interesting subject that’s well worth digging into…
    Thanks for adding fresh angles PhatRik

Leave a Reply