Our new platform is already available at www.gandi.net

Go to the new Gandi

Une faille de securité dans le logiciel de virtualisation QEMU a été annoncée en début de semaine dernière.

Baptisée Venom et identifiée par le code CVE-2015-3456, cette faille permettrait à un attaquant d'exploiter les hôtes vulnérables depuis une machine virtuelle.

Suite à cette annonce, nous avons immédiatement déployé un correctif qui venait s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer certaines VM pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Ce redémarrage préventif n'impactera qu'une petite partie de nos clients. Seuls les clients concernés seront contactés directement par email pour leur permettre de réagir ou d'anticiper le redémarrage de leurs services.

Les VM des clients concernés (sauf si elles ont été redemarrées entre temps) seront redémarrées lundi 25 mai à 11:59pm PDT, soit mardi 26 mai à 07:59am UTC.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.


Suite à l'annonce de la faille de sécurité Ghost, nous vous recommandons vivement de procéder à la mise à jour de vos serveurs en installant les paquets mis à votre disposition par les éditeurs de votre distribution.

Cette faille, qui affecte depuis novembre 2000 la bibliothèque glibc utilisée sur la plupart des distributions Linux et d'autres variantes d'Unix, est très sérieuse, puisqu'elle permet l'exécution de code à distance.

Nous nous assurons de la mise à disposition des paquets correctifs au plus vite sur mirrors.gandi.net

Sont d'ores et déjà disponibles les correctifs suivants :

Nous tâcherons de mettre cette liste à jour au fur et à mesure que les différents éditeurs publieront leurs correctifs.

Si vous êtes client Simple Hosting, nous vous recommandons de redémarrer votre instance.


A partir du mercredi 22 octobre [1], Gandi peut délivrer les certificats SSL en SHA-2 pour les certificats de type Standard, Pro ou Business. Le SHA-1 et SHA-2 sont des familles de fonctions de hachages utilisées pour signer les certificats. Comme bien souvent lorsqu'il s'agit de sécurité, de nouvelles versions sont publiées lorsque des problèmes de sécurité inhérents à l'algorithme sont trouvés dans les précédentes versions. Ce qui est le cas ici pour SHA-2, qui vient progressivement remplacer SHA-1.

Il ne faut cependant pas paniquer, compromettre un certificat émis en SHA-1 reste une tâche ardue.

Notez que si vous utilisez actuellement un certificat en SHA-1 ou que vous souhaitez en acquérir un, vous ne rencontrerez aucun problème. Il s'agit d'une période de transition où les deux algorithmes sont supportés. La fin du support de SHA-1 est prévue au 1er Janvier 2017.

Les autorités de certification, navigateurs internet et les systèmes d'exploitation prennent en charge le SHA-2 pour la majorité. Vous pourrez cependant rencontrer des problèmes d'incompatibilité dans certains cas, par exemple avec Mozilla Firefox car les nouveaux certificats racine n'ont pas encore été ajoutés. Ceci est en cours du côté des différents navigateurs.

Deux possibilités s'offrent à vous :

  • Vous souhaitez proposer uniquement du SHA-2 à vos visiteurs et la question de la compatibilité ne se pose pas : vous pouvez installer uniquement le certificat intermédiaire en SHA-2. Cette solution est optimale en terme de sécurité car toute la chaine de certification sera en SHA-2. Conseillé dans le cas où vous souhaitez mettre en avant la sécurité au détriment de la compatibilité, ou si vous êtes certains que vos visiteurs disposent de navigateurs compatibles, dans le cas d'un intranet par exemple.
  • Vous souhaitez proposer du SHA-2 mais éviter les problèmes d'incompatibilité avec certains navigateurs qui n'ont pas encore mis à jours les certificats racine : Vous pouvez utiliser le certificat intermédiaire en SHA-2 ainsi que le cross-signed. Cependant, le dernier élement de la chaine de vérification sera en SHA-1, ce qui n'est pas optimal en terme de sécurité. Cette solution est utile durant la période de transition, dès lors que les navigateurs auront effectué la mise à jour, vous pourrez enlever le certificat dit 'cross-signed' de votre applicatif. Conseillé dans le cas où vous souhaitez passer en SHA-2 sans perturber les visiteurs dont le navigateur ne dispose pas des dernierts certificats racine.

Attention, de nouveaux certificats intermédiaires, différents de ceux utilisés pour ceux en SHA-1, ont été émis avec les certificats signés en SHA-2. Veillez à utiliser le bon certificat intermédiaire en fonction de votre certificat. Vous pouvez vérifier la signature du certificat avec la commande :

$ openssl x509 -in example.crt -text -noout|grep Issuer

En fonction du résultat retourné, vous saurez quel certificat intermédiaire installer.

  • Pour les certificats issus en SHA-1 : Issuer: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA
  • Pour les certificats issus en SHA-2 : Issuer: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA 2

Voici un exemple de chaine de certification valide pour un certificat SHA-2 :

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

Règles de livraison en SHA-1 et SHA-2 :

Jusqu'au 1er janvier 2016 :

  • Les certificats ayant une date d'expiration se situant après le 1er janvier 2017 seront délivrés en SHA-2 uniquement, même si la CSR a été signé en SHA-1.
  • Les certificats seront délivrés en SHA-1 si la CSR a été généré en SHA-1
  • Les certificats seront délivrés en SHA-2 si la CSR a été généré en SHA-2 

Après le 1er janvier 2016 :

  • Tous les certificats seront délivrés en SHA-2, quelque soit la signature de la CSR

Notez que vous pouvez tout à fait regénérer votre certificat en SHA-2 si vous disposez déjà d'un certificat, en soumettant de nouveau la CSR signé en SHA-2. N'oubliez pas de mettre à jour le certificat intermédiaire en conséquence sur vos applicatifs.

Pour plus d'information, nous vous invitons à vous rendre sur notre documentation disponible à l'adresse suivante :

[1] - Quelques jours avant cette date, notre partenaire Comodo a commencé à émettre des certificats en SHA-2 dans le cas où la date d'expiration du certificat allait au delà de 2017. Nous n'avons pas été en mesure de répercuter ce changement dans notre documentation à ce moment là, nous tenons à nous en excuser. C'est désormais chose faite, vous retrouverez toutes les informations nécessaires à la mise en place de votre certificat émis en SHA-2 en suivant les liens ci-dessus.


Une vulnérabilité majeure a été révélée par les mainteneurs d'OpenSSL, voir la CVE-2014-0160 [2].

Vous devez prendre les mesures nécessaires afin de préserver la sécurité de vos services utilisant des certificats X509/SSL avec cette librairie.

Gandi a pris en compte cette vulnérabilité connue comme le "heartbleed" bug [1], touchant les versions 1.0.1 jusqu'à 1.0.1f d'OpenSSL. La version 1.0.1g ou la version 0.9.8 ne sont pas touchées.

Cette faille de sécurité existe depuis un moment et il y a une probabilité que des certificats X509/SSL aient été compromis, de manière indétectable.

Afin de résoudre ce problème, et uniquement si vous utilisez cette version d'openssl, vous devrez effectuer les opérations suivantes :
  • si vous utilisez un certificat SSL sur notre plateforme PaaS (SimpleHosting) ou via notre accélérateur web, nous avons corrigé cette faille dans la nuit, nous vous donnerons plus de détails sur l'exposition de vos données.
  • si vous utilisez notre plateforme IaaS, aussi appelée Gandi Serveur Cloud, ou un autre fournisseur d'hébergement dédié/virtualisé, en premier lieu, vous devez mettre à jour la version d'OpenSSL sur tout serveur que vous administrez vous-même (voir les mises à jour de sécurité de votre gestionnaire de paquets, par exemple, avec Debian, mettez à jour la liste des paquets avec apt-get update, puis installez la dernière version d'OpenSSL avec apt-get install openssl, ensuite redémarrez tout service utilisant cette librairie, assurez vous bien d'utiliser le dépôt officiel debian-security),
  • si vous utilisez nos certificats SSL sur des services externes, il faudra, après avoir vérifié la version d'OpenSSL utilisée, dans un second temps, regénérer la clé privée et le certificat X509/SSL correspondant, voir le tutoriel suivant pour obtenir de l'aide : http://wiki.gandi.net/fr/ssl/regenerate


Page   1 2
Change the news ticker size