Comment les autorités de certification fournissent-elles les preuves des logsÌýCT ?
Depuis le 1er janvier 2015, toutes les principales autorités de certification (AC) doivent implémenter la journalisation CT (Certificate Transparency) pour les certificats SSL EV. Il en va de même pour les certificats SSL/TLS DV et OV depuis le 1er mai 2018.
Le mécanisme utilisé pour fournir les preuves peut toutefois varier d’une AC à l’autre. Actuellement, ÃÛÌÒTV prend en charge chacune des trois méthodes disponibles pour transmettre des SCT (Signed Certificate Timestamp) et intègre par défaut les SCT des deux logs Google et du log ÃÛÌÒTV. Il s’agit de l’approche la plus simple puisqu’aucune action n’est requise de la part des opérateurs de serveurs. Les clients souhaitant utiliser une extension TLS ou la technique de l’agrafage OCSP (OCSP stapling) doivent nous contacter pour obtenir plus d’informations sur les changements requis côté serveur.
Quelles sont les méthodes disponibles pour transmettre des SCT ?
Les autorités de certification peuvent enregistrer les certificats dans n’importe quel log fiable incluant leur racine. En pratique, les logs traitent les demandes d’inclusion et répondent avec un SCT qui fonctionne comme un reçu en indiquant que le certificat sera ajouté dans un certain délai (c’est ce qu’on appelle le MMD ou Maximum Merge Delay). Cela garantit l’ajout du certificat au log dans un délai défini, sans freiner l’émission ni empêcher l’utilisation du certificat. Le MMD maximum autorisé est de 24 heures – c’est-à -dire que tout certificat nouvellement émis et enregistré apparaîtra dans un log dans les 24 heures suivant la génération du SCT.
Le SCT est inclus dans le certificat tout au long de sa durée de validité et fait partie du processus de négociation TLS qui évalue les SCT pour s’assurer que chacun d’entre eux provient d’un log CT approuvé.
CT prend en charge trois méthodes pour fournir un SCT avec le certificat
Intégration au certificat
Une autorité de certification peut joindre le SCT à un certificat en intégrant les preuves SCT directement aux extensions du certificat. Préalablement à l’émission, elle soumet un précertificat au log, qui renvoie alors le SCT. Elle inclut ensuite les SCT renvoyés en tant qu’extension de certificat dans le certificat émis, avant que celui-ci ne soit signé par l’intermédiaire compétent.
Cette méthode ne nécessite aucune modification du serveur et aucune action de la part de l’opérateur du serveur. Toutefois, elle implique que l’AC obtienne des SCT avant de délivrer le certificat.
Extension TLS
Pour fournir un SCT en dehors du certificat, un opérateur de serveur peut s’appuyer sur une extension TLS spécifique. Une fois que l’AC a émis le certificat, l’opérateur du serveur soumet le certificat au log. Ce dernier envoie le SCT à l’opérateur du serveur, le serveur utilisant l’extension TLS pour distribuer le SCT pendant la négociation.
Cette méthode a l’avantage de réduire la taille du certificat et de ne nécessiter aucune action de la part de l’autorité de certification.
Agrafage OCSP (OCSP stapling)
Un opérateur de serveur peut également fournir un SCT à l’aide de la technique de l’agrafage OCSP. Ici, l’AC émet le certificat et le transmet à la fois au serveur de journalisation et à l’opérateur du serveur. Elle renvoie ensuite le SCT à l’opérateur du serveur dans le cadre de la demande de réponse OCSP du serveur. Cette réponse, qui inclut le SCT en tant qu’extension, est alors fournie aux clients par le serveur lors de la négociation TLS.
Cette méthode exige que l’autorité de certification envoie le certificat au log pendant l’émission, tout en lui permettant de délivrer le certificat avant de recevoir le SCT. En parallèle, elle nécessite que l’opérateur du serveur active l’OCSP Stapling sur le serveur.
