REPLAY WEBINAR CYBERSÉCURITÉ – SSL & HTTPS : définition, importance et risques liés aux certificats SSL

Webinar Cybersécurité Nameshield - SSL HTTPS - Replay

Le navigateur Chrome représente entre 62% et 68% de parts de marché mondial. Alors, quand en 2016 Chrome a annoncé son intention de déclarer le HTTP comme « not secure », le web dans son ensemble se mit à écouter !

Depuis juillet 2018, avec l’arrivée de Chrome 68, les sites en HTTP sont considérés comme « Non Sécurisé », ceux en HTTPS sont marqués « Sécurisé » dans la barre d’adresse.

Et depuis le 25 mai 2018, le RGPD est entré en vigueur et les sites qui récoltent des données personnelles doivent disposer du HTTPS.

De plus, certains nouveaux gestionnaires de noms de domaine imposent également le HTTPS pour pouvoir utiliser le nom de domaine (.app / .dev…).

Passer au HTTPS par défaut sur l’ensemble de vos sites Web est devenu indispensable, en faisant l’acquisition de certificat(s) SSL et permet de bénéficier de différents avantages.

Au programme de ce webinar, nos experts reviennent sur :

  • Qu’est-ce qu’un certificat SSL ?
  • Quels sont les avantages et les risques liés aux certificats SSL ?
  • Quelle stratégie adopter pour vos sites web ?

Retrouvez ce webinar animé par Christophe GERARD, Security Product Manager et Lucie LOOS, Directrice Marketing Experte cybersécurité de Nameshield group, en replay sur la plateforme Webikeo :

L’interface SSL de Nameshield fait peau neuve

L'interface SSL de Nameshield fait peau neuve

Plus intuitive, plus complète, plus jolie… la nouvelle interface SSL de Nameshield arrive le jeudi 13 juin, pour vous permettre de gérer l’ensemble de vos certificats.

Vous disposerez maintenant d’indicateurs clés sur votre portefeuille de certificats, de différentes vues de consultation des certificats (ensemble du portefeuille, vue détaillée, certificats proches de l’expiration, commandes en cours, certificats expirés ou révoqués), d’un système de gestion des Organisations et Contacts et d’un système de commande repensé.

Interface SSL de Nameshield

Enfin, un outil d’aide à la décision a été intégré pour vous aider dans le choix du bon certificat en cas de doute.

La gamme de certificats est mise à jour, à disposition les certificats SSL, RGS, Code Signing, Individuels, tous types et tous niveaux d’authentification.

L’équipe SSL se tient à votre disposition pour une démonstration, un guide complet d’utilisation est à votre disposition pour l’ensemble des opérations et actions disponibles. Contactez-nous directement sur certificats@nameshield.net.

La croisade de Google pour l’adoption du HTTPS par défaut

Le navigateur Chrome représente en octobre 2018, selon les sources et toutes plateformes confondues, entre 62% et 68% de parts de marché mondial. Une croissance d’une régularité implacable depuis le lancement du navigateur qui en fait aujourd’hui un acteur incontournable du web. Alors, quand le 8 septembre 2016, les équipes de développement de Chrome annoncèrent leur intention de déclarer le HTTP comme « not secure », le web dans son ensemble se mit à écouter.

HTTP not secure

L’objectif de Google était d’avertir simplement, et donc visuellement, l’internaute qu’une page en HTTP n’était pas sûre, d’autant plus pour les pages avec saisies de données à caractère personnel (login, mot de passe, informations personnelles, numéro de carte de crédit) :

” We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure. The goal of this proposal is to more clearly display to users that HTTP provides no data security. ”

Un peu plus de deux ans et 17 versions du navigateur plus tard, le temps d’une transition graduée pour un peu plus de douceur, et Google est arrivé à ses fins avec une adoption massive du protocole HTTPS ;  la quasi-totalité des autres navigateurs, Firefox en-tête, ayant suivi la même évolution.

Retour sur l’évolution des indicateurs de sécurité dans Chrome depuis 2 ans :

  1. HTTP not secureSeptembre 2016 – Chrome 53 : le HTTP est la norme, et en dehors de certaines erreurs de sécurité liées à un défaut de la page (notamment lié aux certificats SSL), aucun indicateur particulier concernant le manque de sécurité
  2. Janvier 2017 – Chrome 56 : pour commencer, Chrome met l’accent sur les pages contenant des informations sensibles pour l’internaute, telles que la saisie de mot de passe ou de numéro de carte de crédit. Firefox s’aligne immédiatement.
  3. Octobre 2017 – Chrome 62 : Google avance vers un test grandeur nature du traitement de l’ensemble des pages HTTP considéré comme non sécurisé avec le lancement en mode « Chrome Incognito » de l’indicateur HTTP « Not secure » au lancement de la page, quel que soit son contenu
  4. Juillet 2018 – Chrome 68 : toute page chargée en HTTP, quel que soit son contenu, quel que soit le mode de navigation, est désormais considéré comme « not secure »
  5. Septembre 2018 – Chrome 69 : pour Google, HTTPS est désormais la norme. La prochaine étape, pour le moins controversée, consiste à éventuellement faire disparaître le cadenas de sécurité tant apprécié des internautes.HTTP not securePour beaucoup c’est un sérieux pas en arrière, il faudra suivre de près cette évolution et penser à mettre en place des certificats SSL Extended Validation EV, qui pour l’instant ne sont pas remis en cause par Google.Validation EV
  6. Octobre 2018 – Chrome 70 : c’est maintenant !Chrome 70Désormais, l’affichage des pages HTTP contenant des informations sensibles pour l’internaute, telles que la saisie de mot de passe ou de numéro de carte de crédit, est barré d’un indicateur non sécurisé et pour la  première fois de couleur rouge. Les autres pages HTTP sont indiquées non sécurisées en gris. Les pages HTTPS classiques avec un cadenas noir et celles avec un certificat EV affichent en plus le nom de la société… vous suivez ?
    1. Date non définie – Chrome XX : la finalité de Google est la dualité sur le traitement des urls avec HTTPS ouvertement affichés en rouge pour alerter l’internaute et le HTTPS considéré comme normal, donc ne bénéficiant plus d’aucun indicateur « positif » :

Certificats SSL

  1. HTTP à la CorbeilleDate non définie – Chrome YY : toujours dans une optique d’augmentation de la sécurité et de protection des identités, Google a dans ses cartons une réflexion en cours sur la fin du système d’url tel que nous le connaissons aujourd’hui… Pour le remplacer par un système nouveau et plus simple, affaire à suivre…

D’ici là, et si cette réflexion n’a pas encore été menée au sein de votre entreprise, il est grand temps de passer l’ensemble de vos sites web et applications en HTTPS. La réflexion doit également comprendre le fait d’insérer le nom de votre entreprise dans la barre d’adresse des navigateurs, au moins sur les sites vitrine et à fort trafic.

Les pages Facebook évoluent, les sites Internet traditionnels également

Les pages Facebook évoluent, les sites Internet traditionnels également
Source de l’image : mohamed hassan via Pxhere

Alors que Le Monde se rend compte de l’évolution des pages qui sont renommées au fil du temps sur Facebook, passant d’un intitulé à un autre, interrogeons-nous quelques instants sur les sites Internet traditionnels, qui possèdent un nom de domaine.

Le monde évolue, les environnements et les entreprises, associations ou autres structures également. Même si XEROX communique depuis le 9 janvier 1996 avec le nom de domaine XEROX.COM, les noms de domaine vivent leurs périodes d’enregistrement, d’utilisation et d’abandon.

Ainsi, alors que l’on estime à 340 millions de noms de domaine existant actuellement, plus d’un milliard de noms de domaine ayant existé ont pu être enregistrés.

Acceptons que nous puissions vivre dans un monde mouvant, évoluant avec le temps. Comment être certain d’être sur le bon site Internet si nous nous référons aux noms de domaine ? Le certificat SSL ?

Oui, s’il s’agit d’un certificat EV (niveau d’authentification élevé avec un contrôle complet de l’organisation. Les règles pour l’attribution d’un certificat EV sont définies par le forum CA/Browser et sont strictement contrôlées).

Que faire de plus ? Il est nécessaire de proposer une solution pérenne quant à l’identification de l’émetteur afin que chacun puisse être en confiance sur Internet, par exemple pour le titulaire du nom de domaine, adopter systématiquement un certificat EV avec le niveau d’authentification le plus élevé. Côté utilisateur, il faut être vigilant et vérifier les données propriétaire du site visité.

Alors que la revente de noms de domaine expirés pour des objectifs de SEO ou de phishing continue à évoluer, il est primordial d’assurer une gestion commune Marques, Noms de domaine et Certificats SSL.

Nameshield vous accompagnera dans cette démarche, n’hésitez pas à prendre contact avec nos experts.

RGPD – Quel impact sur vos certificats SSL

RGPD – Quel impact sur vos certificats SSL
Source de l’image : mohamed_hassan via Pixabay

Que dit le RGPD en termes de SSL ?

« Dès lors qu’un site peut traiter des données personnelles, simplement avec la création d’un compte utilisateur, la conformité au RGPD requiert a minima que le site soit protégé par un protocole HTTPS. Ce protocole est une protection a minima que tout gestionnaire de site internet ne peut plus se permettre de ne pas avoir. »

Le règlement européen de protection des données (RGPD) exige donc que les données personnelles soient traitées « de façon à garantir une sécurité appropriée ».

Entré en vigueur le 25 mai dernier, son impact sur la gestion de votre portefeuille de certificats SSL n’est pas neutre.

RGPD et procédures d’authentification

Les Autorités de Certification, quelles qu’elles soient, se sont toujours appuyées sur le WHOIS du nom de domaine à certifier pour valider que le demandeur d’un certificat dispose de l’accord de l’exploitant technique du nom de domaine qu’il veut sécuriser.

Pour cela, une des étapes d’authentification prévoyait qu’un mail soit envoyé sur l’une des adresses mails (admin ou technique) présente sur le WHOIS afin de valider la commande.

Mais le RGPD est passé par là et les bureaux d’enregistrement n’ont plus le droit de fournir les données personnelles des propriétaires de nom de domaine sans leur consentement explicite, ce qui rend la base de données WHOIS inexploitable par les Autorités de Certification pour envoyer leur mail de validation.

Face à cette situation, les Autorités de Certification proposent d’envoyer par défaut ce mail de validation à l’une des adresses génériques suivantes :

admin@domaine.com
administrator@domaine.com
postmaster@domaine.com
webmaster@domaine.com
hostmaster@domaine.com

Mais que faire si aucune de ces adresses n’existe ou s’il est trop compliqué de la faire créer ?

Les Autorités de Certification offrent la possibilité de valider que vous avez bien l’accord de l’exploitant technique du nom de domaine, par le biais d’une vérification d’un record TXT dans la zone de DNS du nom de domaine à certifier.

En constatant la présence de ce record TXT, l’Autorité de Certification pourra :

  • délivrer le certificat si celui-ci est un simple certificat DV (Validation du Domaine)
  • poursuivre vers les autres étapes d’authentification s’il s’agit de certificat OV (Validation de l’Organisation) ou EV (Validation Etendue).

Quoiqu’il en soit, le RGPD change la donne et impacte significativement l’industrie du SSL puisque la solution idéale pour obtenir un certificat rapidement passera soit par la création d’une des 5 adresses mail précitées, soit, si cette option était trop compliquée, par la mise en place de record TXT (qui impliquerait une augmentation des délais d’obtention).

Quel avantage à passer par Nameshield pour la gestion de son parc SSL ?

En qualité de Registrar, Nameshield propose un avantage unique sur le marché pour ses clients SSL.

Une pré-authentification de chaque commande permet en effet d’agir en amont de l’Autorité de Certification afin d’anticiper tout blocage et, le cas échéant, d’agir dans les meilleurs délais :

  • Modification d’un WHOIS,
  • Edition de la zone pour mettre en place un enregistrement TXT (si les DNS sont ceux de Nameshield)
  • Création d’alias admin@, administrator@, webmaster@, postmaster@, hostmaster@ (si les MX sont ceux de Nameshield)

N’hésitez pas à faire appel à notre service SSL dédié si vous avez la moindre question sur le sujet.

[INFOGRAPHIE] Passer son site web en HTTPS : Pourquoi ? Et quel certificat SSL choisir ?

En juillet 2018, avec l’arrivée de Chrome 68, les sites en HTTP seront considérés comme « Non Sécurisé », ceux en HTTPS seront marqués « Sécurisé » dans la barre d’adresse.

Et depuis le 25 mai 2018, le RGPD est entré en vigueur et les sites qui récoltent des données personnelles devront disposer du HTTPS.

De plus, certains nouveaux gestionnaires de noms de domaine imposent également le HTTPS pour pouvoir utiliser le nom de domaine (.app / .dev…).

Passer au HTTPS par défaut sur l’ensemble de vos sites Web va devenir indispensable, en faisant l’acquisition de certificat(s) SSL, avec les avantages suivants :

Confidentialité des échanges, authentification forte et intégrité des communications entre les internautes et vos sites web, jouant sur le niveau de confiance des internautes envers vos sites web et plus généralement votre image de marque liée à la sécurité en ligne.

Mais comment choisir le certificat qui répond à vos besoins ? Ci-dessous notre guide pour vous aider dans votre choix :

Passer son site web en HTTPS : Pourquoi ? Et quel certificat SSL choisir ?

Nameshield vous accompagne

Notre équipe d’experts SSL vous accompagne dans la formation de vos équipes, organise régulièrement des réunions d’information au sein de ses locaux pour vous permettre d’échanger avec d’autres acteurs du marché, met à votre disposition les outils nécessaires à la prise de décision (audit, analyse, conseil) et vous accompagne au quotidien sur tous ces sujets.

A noter : Le 21 juin prochain à Paris, un petit-déjeuner sera organisé autour de ce thème.
Pour plus d’informations et pour vous y inscrire ☛ Invitation au nameshield.cafe.

Chrome 68 : en juillet 2018, les sites en HTTP seront considérés comme « Non Sécurisé »

Chrome 68 : en juillet 2018, les sites en HTTP seront considérés comme « Non Sécurisé »

Nous y sommes ! Google vient d’annoncer dans ce post son intention d’indiquer l’ensemble des pages en HTTP, quel que soit leur contenu, comme étant « non sécurisé ».

Chrome 68 : en juillet 2018, les sites en HTTP seront considérés comme « Non Sécurisés »
Source: Google Security Blog

Le changement est prévu pour le mois de Juillet 2018, avec l’arrivée de la version 68 du fameux navigateur, et confirme la volonté de Google de sécuriser le web. Pour Google le HTTPS doit continuer à être adopté massivement et devenir le standard.

Ce n’est pas une surprise puisque Google a déjà opéré de nombreuses évolutions dans cette direction. Tout d’abord en annonçant un impact positif sur le référencement naturel des sites dont la page d’accueil serait en HTTPS (2014), puis en supprimant le cadenas sur le HTTP (2016), ensuite en indiquant les fameux mots « Non sécurisé » pour toutes les pages de saisies de données personnelles encore en HTTP (2017), et enfin depuis la version 62 avec le mode de navigation incognito affichant déjà toutes les pages HTTP comme « non sécurisé » (2017).

Toutes ces évolutions ont fait l’objet de post sur le blog sécuritaire de Google et étaient systématiquement accompagnées de la fameuse phrase « eventual treatment of all HTTP pages in Chrome : Not Secure » en fin de paragraphe.

Et ça marche ! L’usage du HTTPS se démocratise

Selon Google plus de 68% du trafic généré par Chrome sur Android et Windows est désormais protégé contre plus de 78% sous Chrome OS et Mac. Sur les 100 plus importants sites du monde 81% sont en HTTPS par défaut.

Mais qu’est-ce que le HTTPS ?

Il s’agit d’une extension sécurisée du protocole HTTP, le « S » pour « Secured » signifie que les données échangées entre le navigateur de l’internaute et le site web sont chiffrées et ne peuvent en aucun cas être espionnées  (confidentialité) ou modifiées (intégrité). Obtenir le sacro-saint « S » passe par l’acquisition et l’installation d’un certificat SSL/TLS auprès d’une Autorité de Certification reconnue.

Comment se préparer ?

Demain tous les sites web seront concernés, du site web de vente en ligne au simple site vitrine, tous devront passer au HTTPS pour rassurer les internautes. Si la réflexion n’est pas déjà lancée au sein des équipes web et marketing de votre entreprise, il est urgent de se positionner.

  • Former et informer vos équipes : HTTPS, certificats SSL ;
  • Définir votre stratégie de certification : Autorité de Certification, types de certificats, workflow ;
  • Identifier l’ensemble des sites web de votre société… et définir les priorités d’action :
    1. Sites corporate, vitrine, flagship : prévoir de passer en HTTPS par défaut au plus tôt ;
    2. Sites contenant un espace de saisie de données personnelles (formulaire, login, password, récupération de mot de passe, achats en ligne) => vérifier la présence de HTTPS
    3. Sites secondaires
  • Préparer la transition vers le HTTPS avec vos équipes web
  • Effectuer la transition vers le HTTPS des sites identifiés et surveiller le bon déroulement
  • Gérer vos certificats
  • Nameshield vous accompagne

    Notre équipe d’experts SSL vous accompagne dans la formation de vos équipes ; organise régulièrement des réunions d’information au sein de ses locaux pour vous permettre d’échanger avec d’autres acteurs du marché ; met à votre disposition les outils nécessaires à la prise de décision (audit, analyse, conseil) et vous accompagne au quotidien sur tous ces sujets.

    Nameshield est aussi fournisseur reconnu de solutions de sécurisation de vos sites web : certificats SSL, DNS, registry lock, n’hésitez pas à contacter nos équipes pour plus de renseignements.

A noter : un petit-déjeuner est organisé autour de ce thème, le 21 juin prochain à Paris, n’hésitez pas à vous y inscrire. Pour plus d’informations et pour vous y inscrire ☛ Invitation au nameshield.cafe.

Réduction des certificats SSL à 2 ans maximum

Réduction des certificats SSL à 2 ans maximum

Le CAB Forum, l’organisme qui définit les règles d’émission et de gestion des certificats SSL a approuvé la réduction des certificats SSL à une durée de 2 ans contre 3 précédemment. Initiée par les navigateurs, Chrome et Mozilla en tête, cette décision va dans le sens d’un Internet toujours plus sécurisé en obligeant les acteurs à renouveler plus souvent leurs clés de sécurité et rester sur les derniers standards du marché.

Cette décision sera applicable pour toutes les Autorités de Certification au 1er Mars 2018. Afin d’assurer une transition en douceur, Nameshield ne proposera plus de certificats d’une durée de 3 ans dès le 1er Février 2018.

Quelle incidence pour vos certificats ?

Les nouveaux certificats auront donc une durée maximale de 825 jours (2 ans et 3 mois pour couvrir la possibilité de renouvellement anticipé de 90 jours). Les certificats EV étaient déjà dans ce cas de figure, sont donc concernés les certificats DV et OV sous toutes leurs formes (standard, multi-sites ou wildcard). Rien de particulier pour ces certificats.

Pour les certificats existants, cette nouvelle durée aura une conséquence puisque qu’elle s’appliquera à tous les certificats à partir du 1er Mars. Un certificat de 3 ans émis récemment et qui aurait besoin d’être remplacé au-delà du délai des 825 jours devra donc être de nouveau authentifié. Il est donc important de le savoir pour éviter des réémissions en urgence, y compris pour le simple ajout d’un SAN. Il faudra donc vérifier au préalable si le certificat à remplacer risque d’être impacté, c’est le cas des certificats DV et OV, les EV ne sont là non plus pas concernés.

L’équipe SSL de Nameshield vous préviendra quant aux certificats concernés.

Le CAA devient obligatoire dans le petit monde du SSL

Ou comment en profiter pour mettre en place une stratégie de certification propre à votre société ?

Le CAA devient obligatoire dans le petit monde du SSL

En Janvier 2013, un nouveau type de Resource Record DNS a vu le jour pour améliorer la chaîne de contrôle dans l’émission des certificats SSL. Ce record appelé CAA pour Certificate Authority Authorization permet de préciser pour un nom de domaine donné, quelles sont les Autorités de Certification autorisées à émettre des certificats.

C’est une création extrêmement intéressante, particulièrement pour les grandes sociétés et groupes dont les équipes techniques sont éparpillées dans le monde et pour lesquelles il est souvent difficile d’imposer une stratégie globale de certification. Il n’est pas rare que les sociétés découvrent par hasard l’existence de certificats demandés par des équipes ne connaissant pas les processus, par des consultants externes, émis par des Autorités de Certification ayant une mauvaise image, ou encore pour des certificats de faible niveau d’authentification (DV). La mise en place de record CAA sur vos noms de domaine est une bonne solution pour contrôler ce que font les équipes et l’actualité du monde du SSL va vous y aider.

En effet, si le CAA a été détaillé dans la RFC-6844 de 2013, il n’était jusqu’à présent pas obligatoire pour une Autorité de Certification, de vérifier si elle était autorisée ou non à émettre un certificat sur un nom de domaine donné, d’où une certaine inutilité de la chose et une adoption très faible.

8 Septembre 2017 – Le CAA checking devient obligatoire

Il aura fallu attendre mars 2017 et un vote positif du CAB/forum (ballot 187) pour rendre cette vérification obligatoire. Depuis le 8 septembre, les Autorités de Certification se doivent de faire cette vérification sous peine de sanctions de la part du CAB/forum et des navigateurs, l’actualité récente entre Google et Symantec nous a montré à quel point ce n’est pas dans leur intérêt.

Trois cas de figure se présentent lors de cette vérification sur un nom de domaine donné :

  • Un CAA record est en place et mentionne le nom de l’Autorité de Certification, celle-ci peut émettre le certificat ;
  • Un CAA record est en place et mentionne un nom d’Autorité de Certification différente, celle-ci NE peut PAS émettre le certificat ;
  • Aucun CAA record n’est en place, n’importe quelle Autorité de Certification peut émettre un certificat SSL

CAA found - not found : Le CAA devient obligatoire dans le petit monde du SSL

Il est important de noter que pour un nom de domaine donné, plusieurs records CAA peuvent être déclarés. Un outil simple (parmi tant d’autres) pour tester vos noms de domaine est disponible en ligne : https://caatest.co.uk/

Comment profiter du CAA pour ma société ?

Si ce n’est pas déjà fait, l’avènement du CAA checking est l’opportunité pour votre société de définir une stratégie de certification et de pouvoir s’assurer qu’elle soit respectée. Définir une (ou plusieurs) Autorité de Certification qui correspond à vos valeurs et à votre attente en terme de qualité de service est une première étape. Il faudra pour cela mettre autour de la table les intervenants du marketing pour valider l’impact sur l’affichage dans les sites web et les services techniques pour s’assurer de la qualité du fournisseur choisi. Il conviendra ensuite de déclarer ces records CAA dans les différentes zones de vos noms de domaine.

Il convient ensuite de bien communiquer auprès de l’ensemble des opérationnels pour qu’ils prennent conscience des règles imposées au sein de la société, afin de ne pas les bloquer dans l’obtention d’un certificat. En effet, l’expérience de Nameshield montre que très souvent les certificats SSL sont demandés dans l’urgence ; de plus les dernières versions des navigateurs ne sont pas tendres vis-à-vis des erreurs de certificats en affichant de manière ostentatoire du « Not Secure ». En conséquence, bloquer l’émission d’un certificat parce que la communication n’est pas passée peut être dommageable.

Une telle stratégie présente de réels avantages dans la maîtrise des certificats, sur le plan marketing, technique, maîtrise des risques et coûts liés aux certificats. Il convient de la mener en toute connaissance de cause et pour se faire, notre équipe d’experts SSL peut vous accompagner.

Du mouvement dans le monde du SSL : Digicert rachète l’activité certificats de Symantec

Digicert rachète l’activité certificats de Symantec

Digicert a annoncé, mercredi 2 août, le rachat de la branche Website Security Business de Symantec (incluant notamment le business SSL, et quelques autres services). C’est la conséquence directe du conflit qui oppose depuis quelques mois Symantec à Google.

 

Compte Twitter de DigiCert - Digicert rachète l’activité certificats de Symantec
Compte Twitter de DigiCert

 

Vous avez certainement entendu parler de ce différend qui oppose les deux sociétés sur un certain nombre de certificats émis par Symantec et la possible perte de confiance envers ces certificats dans les prochaines versions de Chrome. Beaucoup d’informations et de dates ont circulé sur le sujet, parfois contradictoires, et il peut être délicat d’évaluer l’impact sur vos propres certificats.

Nameshield, en tant que partenaire Platinum de Symantec, a suivi de très près le développement de cette affaire pour s’assurer que ses clients et partenaires ne risquent pas d’être impactés et de subir une perte de confiance au sein des navigateurs. Les tout derniers développements de cette affaire nous amènent à communiquer les informations importantes qui suivent.

Que s’est-il passé ?

Google et Symantec ont eu un premier différend en 2015, les équipes de Symantec prenant alors pour exemple, lors de sessions de formation de leurs employés, des certificats souvent basés sur le CN google.com, en les émettant réellement pour ensuite les supprimer. C’était objectivement une erreur et Google a sanctionné Symantec en rendant obligatoire l’inscription de l’ensemble des certificats au sein de la base Certificate Transparency, ce qui depuis est devenu un standard du marché et une obligation pour toutes les Autorités de Certification. Cette décision était effective au 1er Juin 2016.

Au début de l’année 2017 Google et Mozilla ont fait part de la découverte de 127 certificats Symantec comportant des irrégularités, amenant une enquête approfondie de la part de Google qui aurait trouvé près de 30 000 certificats impactés. Google a décidé de sanctionner fortement Symantec en réduisant à 9 mois la durée des certificats et en voulant supprimer le statut EV pour les certificats Symantec dans un délai très court. Symantec a pour sa part réagi immédiatement en sanctionnant 4 partenaires à l’origine des erreurs. De nombreuses discussions entre ces deux groupes, et avec de nombreux acteurs importants de l’industrie, ont eu lieu depuis le mois de Mars 2017. Une partie de ces publications, propositions et contre-propositions ont semé la confusion.

Ces différentes discussions ont donc amené Google et Symantec à un accord sur une méthode et un calendrier de transition vers une nouvelle infrastructure PKI pour Symantec. Google a communiqué officiellement vendredi 28 juillet sur le sujet. Cette communication peut être consultée ici.

Symantec s’engage à créer une nouvelle infrastructure PKI en collaboration avec un tiers pour prouver sa bonne foi, répondre aux exigences de transparence de Google et maintenir le haut degré de confiance dont le groupe a toujours bénéficié de la part des internautes. Ce changement d’infrastructure va intervenir au 1er décembre 2017 et nécessitera le remplacement (ou le renouvellement le cas échéant) de l’ensemble des certificats existants pour les marques Symantec, Thawte, Geotrust et RapidSSL. Ce délai allongé permettra une transition en douceur, sans impact sur les internautes.

Depuis le 2 août, nous savons que ce tiers de confiance sera donc Digicert.


Quel calendrier ?

Google distingue les certificats Symantec émis avant le 1er Juin 2016 de ceux émis après cette date (inscription obligatoire dans Certificate Transparency). La perte de confiance dans ces deux catégories de certificats arrivera au travers de deux versions différentes de Chrome d’où le calendrier suivant :

– Catégorie 1 : les certificats émis avant le 1er juin 2016 devront être remplacés (ou renouvelés *) entre le 1er décembre 2017 et le 15 mars 2018 (arrivée de la beta Chrome 66).

– Catégorie 2 : les certificats émis  entre le 1er juin 2016  et le 30 novembre 2017 devront être remplacés (ou renouvelés *) entre le 1er décembre 2017 et le 13 septembre 2018 (arrivée de la beta Chrome 70).

L’urgence éventuelle communiquée par différents acteurs du marché n’a donc pas lieu d’être.

 

* Renouvellement anticipé : un renouvellement peut être effectué jusqu’à 90 jours avant la date d’expiration d’un certificat, sans pénaliser la durée du nouveau certificat délivré.

 

Êtes-vous impacté ?

Oui, si vous disposez de certificats émis avec une des marques de Symantec (Symantec, Thawte, Geotrust, RapidSSL) via Nameshield ou d’autres prestataires avec qui vous travailleriez. Reste à les répartir dans les deux catégories mentionnées. Nous pourrons vous aider à identifier les éventuels certificats impactés ainsi que leur répartition dans les bonnes catégories, afin de prévoir les actions à mener à partir du 1er décembre 2017.

Et Digicert dans tout ça ?

Digicert est une société américaine, dont la part de marché actuelle représente 2,2% du marché mondial selon le dernier rapport de W3tech. C’est une société réputée pour la qualité du travail de ses équipes d’authentification et sa conformité avec les Baseline Requirements du CAB forum. Digicert grossit régulièrement depuis plusieurs années sur des valeurs de sérieux et gère les portefeuilles de certificats de sociétés et sites web très importants, partout dans le monde.

Digicert va devenir un acteur majeur du marché des certificats en reprenant les 14% de parts de marché global de Symantec. Plus intéressant encore, les 40% de parts de marché sur les certificats EV et 30% sur les certificats OV que représente Symantec.

Pour l’ensemble des clients de Symantec, cette acquisition est, sur le papier, une bonne nouvelle. C’est une garantie de continuité dans la qualité des prestations fournies. C’est le gage d’une transition efficace vers la nouvelle infrastructure PKI demandée par Google. Reste à surveiller la capacité de Digicert à respecter le calendrier imposé par Google, nous surveillerons cela de près.

Qu’en pense Nameshield ?

Nameshield fait confiance à Symantec et ses équipes depuis de nombreuses années. D’une part pour la qualité de prestation qui nous est offerte et qui nous permet de vous fournir un service de tout premier ordre, et de l’autre pour l’image de marque et la confiance que ce groupe crée auprès des internautes. La gestion de cette crise Google/Symantec ne remet pas en question la confiance que nous avons dans ce partenaire, et dont l’accompagnement reste irréprochable.

Nous étions par ailleurs depuis quelques mois en relation avec Digicert pour étendre le portefeuille de nos solutions, nous accueillons l’annonce de ce rachat comme une nouvelle positive pour nos clients et partenaires, en étant confiant sur la continuité de service que nous pourrons vous proposer. Pour autant, la confiance que vous nous accordez est primordiale et si vous souhaitez avancer dans une autre direction, Nameshield reste à votre écoute pour vous proposer des alternatives.