Notre nouvelle plateforme est disponible sur www.gandi.net

Découvrir le nouveau Gandi

Starting this Wednesday, October 22[1], Gandi will begin issuing SHA-2 Standard, Pro and Business SSL certificates.

As you may have heard, the SHA-1 signature algorithm is being gradually deprecated in favor of SHA-2 (including SHA256, SHA-512, and so on).

Don't panic, though. At present, it's still really hard to break a SHA-1 hash. But collision attacks against SHA-1 will only become easier, so the sooner everyone migrates, the better.

Note that if you are currently using a SHA-1 certificate or want to buy one, you will still be able to do so. We are now entering a transition period where both the algorithms are supported. SHA-1 will be supported until 1 January 2017.

The majority of certification authorities, browsers, and operating systems already support SHA-2. You may encounter compatibility problems in some cases, for example with Mozilla Firefox[2], as not all root certificates supporting SHA-2 have been added. This process is now underway for various browsers.

If you're ready to migrate to SHA-2, you have two options to choose from:

  • If you want to secure your website or application with SHA-2 only, and the issue of compatibility is not a concern, install your SHA-2-signed certificate along with the SHA-2 intermediate certificate only. This solution is the most secure, since the entire certificate chain will be SHA-2. It is a good option if you want to emphasize security over compatibility, or if you are certain that your visitors have SHA-2 enabled browsers (for example, all the employees of a company are using modern browsers to access a secure site).
  • If you want to provide SHA-2 while avoiding compatibility issues with certain browsers that have not yet updated the root certificates, you can use the intermediate certificate with SHA-2 enabled and add the cross-signed SHA-1 intermediate certificate as well. If so, the last element of the chain of trust will be SHA-1, which is not optimally secure. This option is useful during the transition period: once all relevant browsers have performed the update, you can then remove the cross-signed intermediate certificate. This option is good if you want to switch to SHA-2 without disturbing visitors whose browsers do not have updated root certificates.

Attention! New intermediate certificates, which differ from those used with plain old SHA-1, will be issued with certificates signed with SHA-2. Be sure to use the correct intermediate certificate to match the hashing algorithm used in your main certificate. You can verify the signature of the certificate with the following command:

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

The output will contain lines like the following, indicating the certificate is signed with SHA-1 or SHA-2, respectively.

For certificates issued with SHA-1:

Issuer: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA

and:

Signature Algorithm: sha1WithRSAEncryption

For certificates issued with SHA-2:

Issuer: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA 2

and:

Signature Algorithm: sha256WithRSAEncryption

Here's an example of a valid trust chain for a SHA-2 certificate:

Certificate chain
0 s:/OU=Domain Control Validated/OU=Gandi Standard SSL/CN=example.com
i:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2
1 s:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2
i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

We have put in place some rules to ensure we deliver the right certificates for SHA-1 and SHA-2. Please be sure you review these and get the right certificates for your site or application:

Until 1 January 2016:

  • Certificates with an expiration date after 1 January 2017 will be issued as SHA-2 only, even if the CSR was generated with SHA-1.
  • Certificates with earlier expiration dates will be issued as SHA-1 if the CSR was generated with SHA-1
  • Certificates with earlier expiration dates will be issued as SHA-2 if the CSR was generated with SHA-2 

After January 1, 2016:

  • All certificates will be issued in SHA-2, regardless of the hash specified in the CSR

Note that if you already have a certificate, you can regenerate it as SHA-2 by chosing the regenerate option and using a CSR signed with SHA-2. Remember to update the intermediate certificate on your server if you do this.

For more information, please visit our documentation:

[1] Several weeks ago, our SSL partner, Comodo, began issuing certificates in SHA-2 if the expiration date of the certificate was after January 1, 2017. This caused some confusion for customers whose issued certificates weren't signed with the signature algorithm they were expecting, and who therefore may have installed the wrong intermediate certificates, resulting in some confusion. We weren't able to update our documentation to reflect this in a timely manner, and for this we sincerely apologize. You will now find all the information you need to set up your SHA-2 certificates at the links above.

[2] You can install the root certificate manually by navigating to this URL in Firefox:

http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt

In response to the publication of a security flaw in the design of SSLv3, we have integrated TLS_FALLBACK_SCSV on our hosting platform and mailservers.

The flaw, dubbed POODLE in the announcement by the Google security team, allows a network attacker to force use of a less secure version of the protocol, making it easier to obtain the content of secure connections in plain text.

If for some reason you are not able to upgrade to a modern browser or operation system, you should take steps to protect yourself, such as disabling SSLv3 in your browser.

SSL 3.0 is already an obsolete protocol, so the vast majority of email clients will not notice any difference. However, some very old email clients, operating systems and browsers (Windows XP, IE6) may encounter issues. If you notice any problems connecting to our mailservers, please write to our support team with details.

For those interested in the technical details, there's some good reading over at Ars Technica (new window).

Note: We considered disabling SSLv3 on connections to mail.gandi.net via IMAP and POP3, but decided not to do so immediately. We will do so in the months to come, after taking steps to minimize the impact it will have on our customers' services.

A major vulnerability in the OpenSSL cryptographic software library has just been published (CVE-2014-0160). If you have a Gandi SSL certificate, please read this post carefully before taking action.

This flaw has existed for some time, and there is a possibility that X509/SSL private keys have been compromised undetectably.

This flaw is present in OpenSSL from version 1.0.1 up to and including 1.0.1f, referred to as the "heartbleed" bug (heartbleed.com).

If your servers are using an affected version of OpenSSL (If you aren't sure if your server is affected, you can try a tool like this one, not provided or tested by Gandi):

  • If you are using our SSL certificates on our PaaS platform (Simple Hosting) or via our web accelerator, you should know we fixed this vulnerability as soon as we were informed of it, and we will try to give further details about how your private keys could have been exposed by our platform.
  • If you are using our IaaS infrastructure (Gandi Cloud VPS), or that of another hosting provider, and your servers are using an affected version* of OpenSSL, you need to:
  1. Patch the openSSL version on any server you own and operate yourself by installing security updates provided in your package manager. (For example, on Debian, ensure you're using the official debian-security repository, then run `apt-get update` and `apt-get install openssl`, then restart all services that use SSL.)
  2. Generate new private keys and certificates to restore security of your services (see below if you're using a Gandi SSL certificate).
  • If you are using our SSL certificates, either on our infrastructure (on our PaaS/Simple Hosting instances) or on external services, then it is recommended that you regenerate a CSR and private key. Note: Do not revoke the certificate! Replaced certificates will be automatically revoked (see update below). If you revoke the certificate yourself, you will not be able to replace it afterwards, and you'll instead have to buy a new one.

Additional technical information is available in this GandiKitchen blog post.

========= Update 17 April 2014 =========

If you regenerated a Gandi SSL certificate between 8 and 17 April:

Many customers have regenerated their SSL certificates as a result of the Heartbleed bug. Until today, old certificates which were replaced with new, regenerated ones were not automatically revoked. Due to popular demand, we promised (here and here) to revoke the old certificates.

We sent an email this morning to users who have regenerated a Gandi SSL certificate between 8 and 17 April to notify you that your old certificates will be revoked in 24 hours. Your old certificate will be revoked on the morning of 18 April, Paris time (as early as 1am PST). If you have regenerated a certificate but have not yet installed it on your infrastructure, now is the time to do so!

If you intend to regenerate a Gandi SSL certificate in the future:

We have implemented automatic revocation, which means that from today forward, regenerated certificates will be automatically revoked 48 hours after the replacement certificate has been issued.

If you have questions, please contact support, or tweet us @gandibar.

Page   1 2
Taille du bandeau d'actualités