Introduction
HTTPS et autorités de certification
L'un des piliers structurels de l'internet moderne est que l'établissement d'une connexion entre votre ordinateur et votre site web préféré est incroyablement sûr, du moins du point de vue du trafic sous-jacent. Aucune personne ou organisation ne peut s'immiscer dans vos habitudes internet en observant le trafic entre votre ordinateur et le site web que vous visitez. Tout cela est transparent pour l'utilisateur final. Les technologies sous-jacentes sont néanmoins avancées, mais elles reposent sur la définition de cercles de confiance et d'une infrastructure à clé publique.
Le rôle des certificats SSL/TLS
Si votre entreprise, FooBar, Inc. possède le domaine foobar.com et souhaite que les utilisateurs se sentent en sécurité lorsqu'ils interagissent avec vos gadgets en ligne, vous devez obtenir un certificat SSL/TLS auprès d'une autorité de certification (AC) de confiance. Après l'avoir installé sur votre serveur web, votre site web peut fournir aux utilisateurs un service HTTPS. Cela permet aux systèmes d'exploitation et aux navigateurs web de vérifier que le site web avec lequel ils communiquent est bien foobar.com, et non un imposteur.
Confiance et vérification
Techniquement, n'importe qui peut générer un certificat TLS pour n'importe quel domaine et le mettre en place sur son infrastructure. Toutefois, si le certificat n'est pas émis par une autorité de certification (AC) reconnue et approuvée par ces dernières, les navigateurs et les systèmes d'exploitation signaleront toute tentative d'utilisation de ce certificat par des avertissements de sécurité, ce qui dissuadera les utilisateurs de poursuivre.
Devenir une autorité de certification de confiance
Fonctionner en tant qu'autorité de certification signifie émettre des certificats qui sont reconnus par l'ensemble de l'internet. Pour ce faire, votre certificat racine doit être reconnu par les principales organisations et les principaux fournisseurs qui gèrent une base de données d'autorités de certification racine de confiance. Au minimum, vous devez obtenir la confiance de Google, Mozilla, Apple et Microsoft, ce qui représente un travail considérable.
Conformité et certification
Pour être pris en considération par l'une de ces organisations, vous devez vous soumettre à une série d'audits de conformité et de certifications. Chaque organisation dirigeante a ses exigences minimales :
Le respect de ces normes n'est pas un effort ponctuel, mais un processus continu de maintien de la confiance avec les responsables du magasin racine et la communauté internet. Il s'agit notamment de répondre publiquement à tout incident, qu'il soit découvert en interne ou signalé par la communauté. Google et Mozilla exigent tous deux qu'une autorité de certification de confiance divulgue et réponde publiquement aux incidents en utilisant Bugzilla.
"Les participants au programme Chrome Root DOIVENT divulguer publiquement et/ou répondre aux rapports d'incidents dans Bugzilla, quel que soit l'impact perçu." - Google.
"Au minimum, les opérateurs d'AC DOIVENT signaler rapidement tous les incidents à Mozilla sous la forme d'un rapport d'incident" - Mozilla.
Décision de Google de supprimer Entrust
Entrust est une société privée de logiciels et de matériel qui émet des certificats SSL depuis 1997. Bien que la proportion exacte de son activité dépendant du marché des certificats SSL ne soit pas claire, il est bien connu qu'une partie importante de l'industrie financière dépend uniquement des certificats émis par Entrust.
Dans une annonce, Google a déclaré qu'Entrust ne répondait plus à ses attentes en matière de maintien des normes de sécurité. En conséquence, Google a décidé que les certificats de plusieurs autorités de certification racines d'Entrust ne seraient plus approuvés par défaut pour tous les certificats émis après le 31 octobre 2024.
"Les certificats d'authentification de serveur TLS validés auprès des racines Entrust suivantes, dont l'horodatage du certificat signé (SCT) le plus ancien est postérieur au 31 octobre 2024, ne seront plus approuvés par défaut."
Cette modification signifie que Chrome ne fera pas confiance aux nouveaux certificats émis par ces autorités de certification racine Entrust après la date spécifiée. Les certificats existants continueront à fonctionner jusqu'à ce qu'ils expirent ou soient révoqués.
La raison principale de cette décision semble être le manque de communication d'Entrust concernant les rapports d'incidents, selon Google ; cependant, peu de détails ont été fournis sur les raisons spécifiques, mais nous pourrions être en mesure d'obtenir quelques informations en examinant certains des problèmes passés d'Entrust. Dans la section suivante, nous examinerons le rapport de bogue/incident qui semble avoir été la goutte d'eau qui a fait déborder le vase de la décision de Google de retirer Entrust du magasin de certificats racine de Chrome.
Le dénouement de la confiance d'Entrust
Un ingénieur de Google a signalé à Paul van Brouwershaven (directeur de la technologie chez Entrust) que plus de vingt mille certificats ne contenaient pas un champ obligatoire. Ces certificats auraient dû être considérés comme invalides et marqués comme "mis-issued" (mal émis). - Entrust a déclaré qu'il s'agissait d'une erreur due à une mauvaise interprétation des exigences récemment modifiées.
Le véritable drame a commencé après qu'un utilisateur a fait remarquer qu'Entrust était toujours des certificats erronés[Commentaire n°3]. Entrust avait-elle corrigé son erreur ? Pour l'instant, c'était incertain.
Entrust déclare ensuite qu'il n'était pas prévu d'arrêter l'émission en cours ou de révoquer les certificats existants, car elle considérait que tout cela n'était pas un problème et que la révocation pouvait avoir des conséquences plus négatives que l'autre solution. Ils en ont tiré leurs propres conclusions et interprétations. [Commentaire n°10]
"Nous croyons fermement que le fait de ne pas révoquer la licence et de continuer à l'émettre ne nuit pas à la sécurité, à la fiabilité et à la compatibilité de l'écosystème ou des utilisateurs d'une autre manière".
Quelques autres commentaires sont venus rappeler à Entrust qu'elle ne peut pas simplement interpréter et ignorer les politiques mises en place[commentaire n° 5, commentaire n° 6 ], Commentaire n°7L'AC a proposé une action pour arrêter l'émission de nouveaux certificats et révoquer ceux qui ont déjà été émis, citant le wiki de l'AC Mozilla qui stipule que "Dans les cas d'émission erronée, une AC devrait presque toujours cesser immédiatement l'émission de la partie affectée de son PKI".
Entrust répond une fois de plus et confirme sa réticence à révoquer ces certificats mal émis [Commentaire n°10Cette fois-ci, elle déclare que cela affecterait des milliers de clients, dont la plupart ne sont pas gérés par un processus automatisé, et que la réémission de ces certificats représenterait une quantité de travail ingérable. Dans un dernier acte de défi, le représentant d'Entrust a déclaré ce qui suit :
"Si Mozilla et la communauté attendent des autorités de certification (AC) qu'elles consacrent leur temps précieux à des questions motivées uniquement par des principes, nous risquons d'aller dans la mauvaise direction et d'entraver involontairement les progrès de l'écosystème.
Refus de la communauté.
Un ingénieur logiciel a répondu assez sèchement en expliquant la nature des écosystèmes autorégulés, comme une autorité de certification qui ne respecterait pas ces règles d'autorégulation ; en l'absence d'autorégulation, la seule option (évidemment) est une solution gérée par l'État qui entraverait encore plus le progrès.[Commentaire n°11]. Un autre utilisateur est intervenu peu après pour rappeler à Entrust que le "P" de PKI signifie "Public", et qu'Entrust fournit des services à ce "P" dans "Public", et non l'inverse. [Commentairen° 13]
Et comme le phénix qui se relève, un représentant du programme Google Chrome Root (le rapporteur initial de cette question) a écrit un commentaire détaillé avec des questions très spécifiques.
Ils n'étaient pas satisfaits de la réponse d'Entrust ; l'un des problèmes était le format de la réponse elle-même - il manquait certains détails clés qui sont exigés par les lignes directrices communes de l'AC, tels que la définition du nombre d'actifs affectés, un fait clé qui n'a été découvert que dans les réponses, et non dans le rapport initial. Ils ont également reproché à Entrust d'avoir fait preuve d'un jugement douteux et d'avoir ignoré les préoccupations de la communauté dans un événement qui était à la fois inutile et évitable. [ Commentaire n°19].
Pendant neuf heures, le 18 mars 2024, la section des commentaires de ce numéro est restée silencieuse, avant d'être interrompue par une réponse brève et précise d'Entrust :
"Nous avons cessé de délivrer des certificats erronés et corrigé le profil des certificats EV.
Tous les clients concernés seront informés de la révocation de leur certificat.
Nous allons créer un bug de révocation différée et nous suivrons les autres questions dans les prochains jours". - Entrust / [Commentaire #20]
C'est ainsi que le 18 mars à 15 heures PST, Entrust s'est résigné à leur insistance. Mais ils étaient loin de se douter que ce n'était que le début d'une vague de demandes de renseignements.
"Vous avez donc réussi à mettre fin à l'émission erronée en moins de 10 heures, mais seulement après l'intervention de Google ? Avant cela, vous ne vouliez tout simplement pas arrêter ?" demande JR Moir dans commentaire n°21 - une question valable qui était probablement à l'esprit de beaucoup à l'époque. JR poursuit : "La confiance en Entrust devrait être supprimée". Le premier coup de feu de la révolte a retenti dans le champ herbeux de la sécurité sur l'internet.
Au cours des semaines suivantes, Entrust a interagi avec la communauté pour tenter de recenser tous les certificats concernés. Ce n'est que le 4 avril qu'Entrust a répondu directement aux commentaires et questions initiales du Chrome Root Program dans le commentaire n° 35. Entrust a déclaré que même si sa réponse n'était pas conforme aux attentes établies d'une autorité de certification, l'intention était d'agir dans le meilleur intérêt des clients ou, comme ils l'ont dit, de l'écosystème web. Entrust a ensuite répondu à chacune des questions posées dans le commentaire, a insisté sur le fait qu'il s'agissait simplement d'un oubli et a reconnu sa faute.
"Rétrospectivement, nous reconnaissons que nous aurions dû cesser de délivrer des certificats EV sans le qualificatif de politique dès la confirmation du problème, puis assurer le suivi de ce que nous considérions comme une omission possible dans les lignes directrices EV". - Commentaire n° 35 / Réponse à la question 1 du commentaire n° 19
Le commentaire #35 est plein d'informations précieuses donnant un aperçu de tous les faux pas qu'Entrust a fait tout au long de ce voyage, y compris des détails sur l'ensemble de leur processus d'émission ; de grands efforts ont été déployés dans les explications de certaines des hypothèses qui ont été faites et qui ont conduit à ces décisions ; Ils n'ont pas inclus le champ requis dans les nouveaux certificats parce qu'ils ont pensé à tort qu'il s'agissait d'une erreur dans le texte des lignes directrices de l'autorité de certification elle-même :
"Nous pensions que l'absence de "certificatePolicies:policyQualifiers:qualifier:cPSuri" dans les certificats EV délivrés était due à une erreur dans les lignes directrices EV. - Commentaire n° 35 (Entrust)
Six jours plus tard, Entrust a publié un rapport d'incident mis à jour pour ce problème(commentaire n°41) qui comprenait une chronologie complète des événements. Une réponse qui n'a fait que susciter à nouveau l'ire de la communauté. Dans le commentaire n°44, un utilisateur écrit qu'il espère que d 'autres autorités de certification considéreront cet incident comme une "leçon à retenir", après avoir constaté que, trois semaines plus tard, la moitié seulement des "clients concernés" ont été dépannés et que la moitié seulement des certificats délivrés à tort ont été révoqués. Puis un autre appel à la suppression d'Entrust :
"Ces défaillances répétées montrent clairement que l'on ne peut pas faire confiance à Entrust dans la WebPKI et qu'elle doit être retirée. - JR Moir(Commentaire n°44)
En réponse, le représentant d'Entrust a déclaré que sa base d'abonnés était différente de celle d'autres AC (peut-être plus grandes), faisant peut-être référence à la catégorie de clients à laquelle Entrust s'adresse. Entrust poursuit :
"Nous espérons que les membres de la communauté qui ont de l'expérience dans le domaine où Entrust opère comprennent nos défis et que nous faisons tout ce que nous pouvons pour que nos abonnés soient mieux préparés et plus agiles en cas d'incidents de sécurité" - Entrust(Commentaire #46)
Le fil de discussion devient ensuite silencieux, à l'exception de quelques commentaires ici et là avec des histoires et des récits sur les échecs historiques d'Entrust. Le dernier commentaire en date est celui du responsable du programme Mozilla CA, Ben Wilson, qui demande des actions supplémentaires à Entrust, ce qui a donné lieu à un nouveau ticket ID #1901270 : Entrust : Action Items from June 2024 Report (Points d'action du rapport de juin 2024).
Ce n'est que le dernier drame en date auquel Entrust a été mêlé. En mars 2024, il a été signalé qu'Entrust avait émis par erreur 1 176 certificats parce que son outil n'avait pas détecté certains certificats non conformes. Bien qu'il ne s'agisse pas d'un problème grave en soi, les certificats concernés par cette erreur n'ont pas été révoqués en temps voulu, ce qui a donné lieu à un autre incident signalé au public.
Certains commentateurs ont même fait référence à la nature éparse du suivi et ont souligné qu'Entrust semble blâmer les clients pour leur incapacité à révoquer ces certificats rapidement. Un mois auparavant, il a été signalé qu'Entrust utilisait SHA-1 (un algorithme de hachage obsolète) pour signer les réponses via OCSP et a eu un long échange avec l'ensemble de la communauté, répondant à des questions frustrées sur les raisons pour lesquelles Entrust n'avait pas découvert cette information plus tôt.
Il existe plusieurs autres exemples de perte de confiance du public dans Entrust, la plupart impliquant des réponses tardives et des délais de révocation des certificats. Ces problèmes cumulés expliquent pourquoi Google a décidé de ne plus prendre en charge les certificats émis par Entrust dans son magasin de certificats racine.
Avec plus de deux décennies dans l'industrie et une histoire récente (malheureusement) mal accueillie, il semble que ce soit le début de la fin pour l'autorité de certification d'Entrust. Aujourd'hui, c'est Google ; demain, ce sera peut-être Mozilla et Microsoft.
Il s'agit d'une décision importante qui ne doit pas être prise à la légère. Il y a même des leçons à tirer de cette affaire. L'érosion de la confiance entre un service public et sa communauté peut avoir des conséquences désastreuses.
Horodatage des certificats signés
Les SCT sont des reçus numériques émis par les journaux de transparence des certificats (CT) lorsqu'une autorité de certification soumet un certificat à l'enregistrement. Ces horodatages prouvent que le certificat a été enregistré dans un journal public, ce qui permet un audit public. Lorsqu'une autorité de certification (AC) émet un nouveau certificat, elle l'envoie à un ou plusieurs journaux de transparence des certificats. Une fois que le journal CT a reçu le certificat et créé un enregistrement, il génère un SCT, qui comprend les éléments suivants :
- Un horodatage indiquant la date à laquelle le certificat a été enregistré.
- Le hachage du certificat
- Un identifiant unique pour le journal
- Une signature numérique créée par la clé privée du journal.
Ce SCT est ensuite le plus souvent intégré directement dans le certificat. Voici un exemple de la manière dont on peut visualiser les informations SCT du nom de domaine "www.censys.com" :
echo | openssl s_client \N- -connect www. com:443 2>/dev/null
-connect www.censys.com:443 2>/dev/null | \N- openssl x509 -text -noout
openssl x509 -text -noout | \N- grep -A 11 "Signed Certificate Timestamp" (horodatage du certificat signé)
grep -A 11 "Signed Certificate Timestamp" (Horodatage du certificat signé)
La sortie de cette commande ressemblera à ce qui suit :
Horodatage du certificat signé :
Version : v1 (0x0)
ID du journal : 3F:17:4B:4F:D7:22:47:58:94:1D:65:1C:84:BE:0D:12 :
ED:90:37:7F:1F:85:6A:EB:C1:BF:28:85:EC:F8:64:6E
Horodatage : 21 mai 05:16:30.739 2024 GMT
Extensions : aucune
Signature : ecdsa-with-SHA256
30:45:02:21:00:EC:76:D9:73:19:C7:94:12:EE:60:28:
D7:0B:71:F6:7F:33:60:ED:47:3F:B1:CD:E4:26:59:83:
21:B0:AD:99:5C:02:20:24:98:7F:9B:DC:E5:FD:E8:A9:
1E:B9:25:F7:5E:0C:15:ED:B7:38:2B:5F:C4:68:FB:26:
A9:E9:03:60:D1:CF:F5
- Version : Indique la version du SCT ; ici, il s'agit de la version 1.
- Horodatage : La date et l'heure auxquelles le SCT a été émis.
- Signature : La signature cryptographique qui valide le SCT.
- Log ID : Identifiant unique du journal qui a émis le SCT, représenté par une séquence d'octets hexadécimaux.
Pour trouver le fournisseur de logs pour un "Log ID" donné (où l'on peut trouver des détails sur cette émission), les commandes suivantes peuvent être utilisées :
$ LOGID=$(echo 3F:17:4B:4F:D7:22:47:58:94:1D:65:1C:84:BE:0D:12:ED:90:37:7F:1F:85:6A:EB:C1:BF:28:85:EC:F8:64:6E | \
sed -s 's/://g' | \
xxd -p -r | base64); \
curl -s https://www.gstatic.com/ct/log_list/v3/all_logs_list.json | \
jq ".operators[].logs[]|select(.log_id == \"$LOGID\")|."
{
"description": "Let's Encrypt 'Oak2024H2' log",
"log_id": "PxdLT9ciR1iUHWUchL4NEu2QN38fhWrrwb8ohez4ZG4=",
"key": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE13PWU0fp88nVfBbC1o9wZfryUTapE4Av7fmU01qL6E8zz8PTidRfWmaJuiAfccvKu5+f81wtHqOBWa+Ss20waA==",
"url": "https://oak.ct.letsencrypt.org/2024h2/",
"mmd": 86400,
"state": {
"usable": {
"timestamp": "2022-11-30T17:00:00Z"
}
},
"temporal_interval": {
"start_inclusive": "2024-06-20T00:00:00Z",
"end_exclusive": "2025-01-20T00:00:00Z"
}
}
La sortie ci-dessus nous indique que nous pouvons valider ce SCT en utilisant le serveur "Let's Encrypt 'Oak2024H2' log".
Dans le cas de Google Chrome, une étape supplémentaire (ou contrainte) est ajoutée au processus de vérification pour tout certificat donné. Cette contrainte vérifie si le certificat a été généré le 31 octobre 2024 ou après cette date. Si la contrainte est respectée, le certificat est rejeté.
L'impact sur l'Internet
Nous pouvons examiner l'ensemble des données relatives aux hôtes et aux certificats sur le site Censys pour comprendre la position d'Entrust parmi les autres autorités de certification et l'impact potentiel de ce problème s'il n'est pas résolu dans les plus brefs délais.
Répartition des autorités de certification
Au total, Google a approuvé les certificats de 464 autorités distinctes, ce qui représente 7 559 114 541 (sept milliards) de certificats émis. Parmi ces autorités, Entrust, Inc. arrive en 22e position, avec 3 999 827 (0,05 %) certificats approuvés par Google, et AffirmTrust arrive en 78e position, avec un nombre impressionnant de 37 646.
Les chiffres sont différents si l'on considère les certificats actuellement valides, c'est-à-dire les certificats qui n'ont pas été révoqués ou qui n'ont pas expiré. Au 28 juin 2024, Google fait confiance à 747 659 643 certificats valides émis par 244 autorités de certification distinctes. Entrust, Inc. se classe au 20e rang avec 571 469 certificats en cours de validité, et AffirmTrust au 120e rang avec 625 certificats.
Ces chiffres reflètent le nombre total de certificats émis, et pas nécessairement ceux qui sont actuellement utilisés. Il est impossible de déterminer le nombre de certificats actifs et en cours d'utilisation, car cela nécessiterait l'accès à chaque organisation ou ordinateur individuel. Cependant, en utilisant des données de balayage actuelles et historiques, Censys peut fournir des données sur le nombre de certificats émis par Entrust observés sur l'Internet public.
Entrust sur Internet
Dans l'article original, Google énumère neuf autorités de certification racine différentes appartenant à Entrust et renvoie à chaque entrée correspondante sur crt.sh. À partir de là, nous pouvons noter l'empreinte SHA-256 du certificat de chacune d'entre elles et rechercher les hôtes qui ont l'une de ces neuf empreintes dans leur chaîne de certificats :
| CA émettrice |
Empreinte digitale SHA-256 |
| CN=Entrust Root Certification Authority - EC1 |
02ed0eb28c14da45165c566791700d6451d7fb56f0b2ab1d3b8eb070e56edff5 |
| CN=Entrust Root Certification Authority - G2 |
43df5774b03e7fef5fe40d931a7bedf1bb2e6b42738c4e6d3841103d3aa7f339 |
| CN=Entrust.net Autorité de certification (2048) |
6dc47172e01cbcb0bf62580d895fe2b8ac9ad4f873801e0c10b9c837d21eb177 |
| CN=Entrust Root Certification Authority |
73c176434f1bc6d5adf45b0e76e727287c8de57616c1e6e6141a2b2cbc7d8e4c |
| CN=Entrust Root Certification Authority - G4 |
db3517d1f6732a2d5ab97c533ec70779ee3270a62fb4ac4238372460e6f01e88 |
| CN=AffirmTrust Commercial |
0376ab1d54c5f9803ce4b2e201a0ee7eef7b57b636e8a93c9b8d4860c96f5fa7 |
| CN=AffirmTrust Networking |
0a81ec5a929777f145904af38d5d509f66b5e2c58fcdb531058b0e17f3f0b41b |
| CN=AffirmTrust Premium |
70a73f7f376b60074248904534b11482d5bf0e698ecc498df52577ebf2e93b9a |
| CN=AffirmTrust Premium ECC |
bd71fdf6da97e4cf62d1647add2581b07d79adf8397eb4ecba9c5e8488821423 |
services.tls.certificates.chain.fingerprint = {
02ed0eb28c14da45165c566791700d6451d7fb56f0b2ab1d3b8eb070e56edff5,
43df5774b03e7fef5fe40d931a7bedf1bb2e6b42738c4e6d3841103d3aa7f339,
6dc47172e01cbcb0bf62580d895fe2b8ac9ad4f873801e0c10b9c837d21eb177,
73c176434f1bc6d5adf45b0e76e727287c8de57616c1e6e6141a2b2cbc7d8e4c,
db3517d1f6732a2d5ab97c533ec70779ee3270a62fb4ac4238372460e6f01e88,
0376ab1d54c5f9803ce4b2e201a0ee7eef7b57b636e8a93c9b8d4860c96f5fa7,
0a81ec5a929777f145904af38d5d509f66b5e2c58fcdb531058b0e17f3f0b41b,
70a73f7f376b60074248904534b11482d5bf0e698ecc498df52577ebf2e93b9a,
bd71fdf6da97e4cf62d1647add2581b07d79adf8397eb4ecba9c5e8488821423
}
Industries et organisations concernées
Au moment de la rédaction de ce document, 876 681 hôtes physiques et virtuels utilisaient un certificat délivré par l'une des neuf autorités de certification Entrust. Bien que ce chiffre ne soit pas très enthousiasmant, nous pouvons examiner les feuilles de certificat pour comprendre à quelles organisations et à quels secteurs appartiennent ces certificats.
Nous avons analysé chaque nom de domaine enregistré figurant dans les certificats de feuilles émis par ces neuf autorités de certification Entrust. Dans la mesure du possible, nous avons ensuite classé les domaines en fonction du nombre d'hôtes uniques que l'on trouve actuellement sur l'internet. Nous avons ensuite classé les entreprises et les secteurs d'activité associés pour les certificats comportant dix hôtes ou plus (5 285 noms de domaine). Ici, nous n'incluons pas les sous-domaines, mais uniquement les noms de domaine enregistrés ("www.censys.com" devient "censys.com").
La grande majorité des certificats Entrust émis en ligne concernent les services financiers (254 654 hôtes et 19 151 certificats uniques), la technologie (136 408 hôtes et 9 609 certificats), le divertissement (63 884 hôtes et 1 121 certificats) et le secteur public (58 490 hôtes et 8 044 certificats).
Toutefois, le nombre de certificats de feuilles par secteur d'activité brosse un tableau légèrement différent. Les "Services professionnels" passent de la 9ème à la 3ème place lorsque l'on examine le nombre de certificats feuilles - ce qui indique que si le secteur "Divertissement" est présent sur de nombreux hôtes, il couvre un nombre limité d'entreprises ou de noms de domaine. Toutefois, nous pouvons également constater que le secteur des services financiers reste en tête en termes de nombre d'hôtes et de certificats uniques. En d'autres termes, de nombreuses sociétés financières font confiance à Entrust.
Les 20 premières industries par nombre d'hôtes et de certificats de feuilles.
Organisations
Nous pouvons également examiner les organisations spécifiques qui composent ces industries pour mieux comprendre qui sera affecté par la rupture de la relation d'Entrust avec Google. Là encore, nous séparons les statistiques en fonction du nombre d'hôtes et de certificats de feuilles uniques trouvés avec un émetteur Entrust sur l'Internet.
Ici, nous pouvons voir des résultats très différents en fonction de la façon dont vous classez les données. La société Disney possède des certificats Entrust sur plus de 57 000 hôtes réels et virtuels uniques, mais seulement 636 certificats de feuilles uniques. Un rapide Censys Search en révèlera les raisons.
De nombreux hôtes sur lesquels nous voyons des certificats émis par Entrust pour "*.disney.com" se trouvent dans Akamai, un réseau de diffusion de contenu que de nombreuses entreprises de taille moyenne à grande utilisent pour mettre en cache et diffuser leurs données. Alors que Disney ne possède que 636 certificats, ceux-ci ont été trouvés sur plus de 57 000 hôtes "virtuels" dans nos données d'analyse.
Disney s'est classé au premier rang pour le nombre d'hôtes, avec 40 noms de domaine répartis sur 636 certificats uniques, la majorité d'entre eux concernant disney.com et des domaines liés à disney.com. Les vingt premiers domaines liés à Disney avec un certificat émis par Entrust et les statistiques correspondantes sur les hôtes et les feuilles sont présentés ci-dessous.
Cependant, Ernst & Young n'avait que dix noms de domaine que nous avons classés avec 6 200 certificats de feuilles uniques émis par Entrust sur 16 063 hôtes.
Une fois de plus, la plupart de ces certificats ey.com se trouvent chez Akamai. Toutefois, une bonne partie d'entre eux sont également exécutés dans le système autonome de Microsoft, ce qui indique qu'Ernst & Young exploite une grande partie de son infrastructure dans Azure.
Mais ces décomptes d'hôtes peuvent être très trompeurs car un seul certificat peut contenir de nombreux noms différents sur lesquels il fait autorité ; par exemple, ce seul certificat Ernst & Young sur la gauche est pour les deux noms de domaine "ey.com" et "eyclienthub.com", donc si vous décomposez les statistiques par nom de domaine enregistré, ce certificat sur un seul hôte serait compté deux fois ; En d'autres termes, il est probablement préférable de regarder le nombre de certificats de feuilles uniques plutôt que le nombre brut d'hôtes pour estimer le niveau d'effort qu'il faudrait faire pour résoudre ce problème.
Que peut-on faire ?
- Bien que les certificats actuellement approuvés ne soient pas affectés par ce changement, si une personne ou une organisation utilise Entrust actuellement et a encore besoin de certificats dans un avenir prévisible, elle doit prévoir d'obtenir ses nouveaux certificats auprès d'une autre autorité de certification approuvée et de mettre à jour l'infrastructure en conséquence.
- Si vous pensez être concerné par ce changement, cette recherche peut être modifiée pour trouver tous les hôtes qu'Entrust émet pour votre domaine (il suffit de remplacer "votredomaine.com : par votre propre nom de domaine).
- Censys Les clients de l'ASM peuvent accéder à un nouveau risque de faible priorité appelé "Entrust Issued Certificate", qui notifiera automatiquement les clients lorsqu'un certificat émis par Entrust est trouvé dans leur environnement.
