Qu’en est-il de la prise en charge de Certificate Transparency (CT) pour les logs, les navigateurs et les autorités de certification ?
Logs
Depuis le mois de février 2018, DigiCert soumet par défaut tous les certificats TLS/SSL nouvellement émis et publiquement approuvés à des logs Certificate Transparency. Ce changement visait à anticiper l’exigence sectorielle imposée par Google, qui est entrée en vigueur en avril 2018. L’objectif était ici de renforcer la sécurité de nos clients, tout en encourageant l’adoption. Pour rappel, avant 2018, la journalisation était uniquement requise pour les certificats EV.
Actuellement, DigiCert gère son propre log CT, qui est également utilisé par Google. En pratique, l’inclusion d’un log exige une disponibilité élevée, confirmée par une période de test de 90 jours. Si un log ne satisfait pas à ces exigences strictes, il est considéré comme non fiable. Dans cette optique, DigiCert a pris des précautions supplémentaires afin que son log soit suffisamment robuste pour gérer le volume de tous les certificats émis.
Navigateurs
Chrome – Chrome a commencé à prendre en charge CT début 2014. Cette exigence s’applique aujourd’hui à toutes les autorités de certification émettant des certificats.
Pour un certificat d’un an, Google exigeait des preuves CT issues de deux logs indépendants. Pour un certificat de deux ans délivré avant que les certificats d’un an ne deviennent la norme en 2020, il fallait produire des preuves CT provenant d’au moins trois logs indépendants. Afin de faciliter la transition pour les autorités de certification, Google a temporairement assoupli son exigence d’indépendance, en autorisant l’inclusion de deux preuves issues des logs Google et d’une autre provenant du log DigiCert. Cette décision avait pour but de garantir un nombre suffisant de logs opérationnels en laissant le temps à davantage d’autorités de certification et de parties intéressées de créer des logs.
Firefox – Actuellement, Firefox ne vérifie et ne requiert pas l’utilisation de logs CT pour les sites que les utilisateurs visitent.
Safari – Apple exige divers SCT (Signed Certificate Timestamp) pour que Safari et d’autres serveurs se fient à des certificats serveur.
Autorités de certification :
Selon la note RFC 9162 de l’Internet Engineering Task Force (IETF), il est prévu que les autorités de certification publiques enregistrent tous leurs nouveaux certificats dans un ou plusieurs logs. Cependant, les détenteurs de certificats, tout comme les tierces parties, peuvent mettre en place leurs propres chaînes de certificats.
Depuis janvier 2015, toutes les principales autorités de certification enregistrent les certificats EV émis sur des serveurs de journalisation CT. Et toute autorité de certification émettant des certificats EV se doit d’utiliser les deux logs Google disponibles ainsi que le log DigiCert pour se conformer aux directives de Google.
Comment l’AC DigiCert assure-t-elle la conformité à Certificate Transparency ?
CT renforce le système des certificats TLS/SSL en créant des enregistrements publiquement vérifiables dans le cadre de l’émission des certificats. Depuis 2015, Google exige des autorités de certification qu’elles enregistrent les certificats EV dans des logs CT publics. Et depuis avril 2018, le géant du web impose également aux autorités de certification d’enregistrer les certificats OV et DV dans des logs CT publics.
DigiCert publie tous les nouveaux certificats TLS/SSL publics dans des logs CT publics depuis le 1er février 2018. Ce changement est sans incidence sur les certificats OV ou DV émis avant le 1er février 2018.
Navigateurs avec politiques Certificate Transparency :
Depuis avril 2018, Google exige des autorités de certification qu’elles assurent la journalisation de tous les certificats TLS/SSL (EV, OV et DV).
De son côté, Apple applique la même exigence depuis le 15 octobre 2018.
Comment le protocole Certificate Transparency a-t-il été créé ?
En 2011, une autorité de certification néerlandaise baptisée DigiNotar a été piratée. L’attaque a abouti à la création de plus de 500 certificats frauduleux émis par la racine de confiance de DigiNotar. Les attaquants ont utilisé ces certificats pour imiter de nombreux sites, notamment Google et Facebook, et pour mener des attaques par interception (MITM) à l’encontre d’utilisateurs peu méfiants.
Ce cas est venu s’ajouter à d’autres incidents de grande envergure impliquant des certificats émis frauduleusement ou par erreur par des autorités de certification (autres que DigiCert). C’est pourquoi Google a décidé de se pencher sur de nouvelles solutions. Deux ingénieurs, Ben Laurie et Adam Langley, ont ainsi trouvé l’idée de Certificate Transparency et ont commencé à développer le framework en tant que projet open source. En 2012, en collaboration avec l’IETF, ils ont créé une version préliminaire esquissant les grandes lignes de Certificate Transparency et, en 2013, ils ont publié une RFC.
En 2013, Google a lancé deux logs publics et fait part de sa volonté d’exiger CT pour tous les certificats SSL EV dans Google Chrome.
Début 2012, DigiCert a commencé à expérimenter l’intégration CT et à donner son avis sur les implémentations CT proposées. En septembre 2013, DigiCert est devenue la première autorité de certification à mettre en œuvre CT dans ses systèmes. En octobre de la même année, l’entreprise est également devenue la première autorité de certification à offrir aux clients la possibilité d’intégrer des preuves CT dans des certificats SSL.
En septembre 2014, DigiCert a soumis un log privé à Google afin qu’il soit inclus dans Google Chrome. Le log DigiCert a été accepté le 31 décembre 2014. DigiCert a été la première autorité de certification à créer un log CT.
