Certification Authority Authorization (CAA), spécifiée par RFC 8659 36, est une fonctionnalité qui permet aux clients ACME d'utiliser un enregistrement DNS spécifique pour limiter les autorités de certification autorisées à émettre pour ce nom de domaine. L’équipe en charge de Let's Encrypt a annoncé qu’elle allait activer l'ACME CAA Account and Method Binding dans son environnement de production.Let's Encrypt est une autorité de certification gratuite, automatisée et ouverte, proposée par l'organisme à but non lucratif Internet Security Research Group (ISRG). Elle délivre gratuitement des certificats à Validation de Domaine (Domain Validated ou DV). Let's Encrypt prend en charge la CAA depuis de nombreuses années, et sa prise en charge est imposée par les exigences de base pour toutes les CA. Certification Authority Authorization est conçue pour permettre au détenteur d'un nom de domaine DNS (le propriétaire d'un site Web) de spécifier à une ou plusieurs autorités de (CAs) l'autorité d'émettre des certificats pour ce domaine ou site web, selon une définition dans le projet RFC 6844 de l'IETF.
Avec les dernières normes industrielles, une CA devra vérifier les enregistrements de la CAA pour s'assurer qu'elle a l'autorité pour émettre les certificats pour un domaine particulier, avant l'émission. Par exemple, si vous êtes propriétaire de ‘’domainexyz.com’’ et que vous souhaitez que les certificats pour ce domaine soient émis par DVP, vous devez créer un enregistrement CAA dans le DNS avec DVP en tant que votre CA de choix. Vous pouvez avoir plus d'un enregistrement CAA si vous travaillez avec plus d'une CA.
Avec la CAA, si un acteur malveillant, ou un autre employé, engage une CA pour émettre un certificat pour ‘’domaine., cette CA doit d'abord vérifier dans le DNS. L'autorité de certification non répertoriée est autorisée à délivrer le certificat pour votre domaine si aucun enregistrement CAA n'existe. Cependant, l'autorité de certification non répertoriée n'est pas autorisée à délivrer le certificat si des enregistrements CAA existent pour d'autres autorités de certification. Cette nouvelle exigence permet d'atténuer les risques de délivrance de certificats par des CA non autorisées.
Il convient de noter que dans le protocole ACME utilisé par les clients de Let's Encrypt pour obtenir des certificats de Let's Encrypt, un compte est essentiellement une clé privée utilisée pour authentifier les demandes à la CA. En bref, cela signifie que seule une personne possédant la clé privée de votre compte ACME peut obtenir des certificats.
Il y a quelques mises en garde à ce sujet :
- Nécessite DNSSEC pour être efficace : pour que cela fonctionne, vous devez utiliser DNSSEC pour votre domaine afin que le contenu de la zone DNS de votre domaine puisse être authentifié de manière cryptographique par la CA ;
- Exige que votre CA utilise DNSSEC : votre autorité de certification doit effectuer toutes les résolutions DNS via un résolveur validant les DNSSEC. Toutefois, cela est pris en charge par Let's Encrypt (la seule CA à prendre en charge ACME-CAA jusqu'à présent) ;
- Vulnérabilité aux autres CA : bien que toutes les autorités de certification soient désormais tenues de traiter les enregistrements CAA, il ne me semble pas que les règles du forum CA/Browser les obligent à utiliser un résolveur validant les DNSSEC pour le faire. Cela signifie qu'un attaquant pourrait être en mesure de tromper une autorité de certification tierce que vous n'autorisez pas par le biais de la CAA et de la faire émettre si elle peut MitM les demandes de l'autorité de certification à vos serveurs de noms. Cela ne protège pas non plus contre les AC qui sont elles-mêmes malveillantes (plutôt que d'être trompées) ou qui délivrent des certificats erronés par négligence ou incompétence. Vous pourrez toujours détecter ces erreurs après coup en utilisant CT, bien sûr. Personnellement, j'espère que le forum CA/Browser rendra obligatoire l'utilisation d'un résolveur validant les DNSSEC pour vérifier les enregistrements CAA à l'avenir. (Cela ne signifie pas que les domaines devront utiliser le DNSSEC, mais que les domaines qui le font seront immunisés contre la falsification de leurs enregistrements CAA) ;
- Vulnérabilité des bureaux d'enregistrement ou action arbitraire : fondamentalement, l'ACME-CAA vise à renforcer la sécurité en s'appuyant sur le DNSSEC. En effet, on pourrait soutenir que le DNSSEC rend les CA redondantes, ce qui est théoriquement le cas via des technologies comme DANE. Il est toutefois intéressant de noter que DANE ne fournit pas de journal de transparence, alors que l'infrastructure de la CA le fait. En combinant l'infrastructure de transparence de la CA et le DNSSEC, il est possible en quelque sorte d’obtenir le meilleur des deux mondes. Toutefois, il convient de noter que cela hérite de toutes les limitations de sécurité des DNSSEC.
Par exemple, votre compte auprès de votre registraire DNS pourrait être piraté, ou votre registraire pourrait être piraté, ou encore votre registraire pourrait être persuadé de détourner votre domaine, que ce soit par un tribunal, un gouvernement ou une agence de renseignement, etc. (Il ne s'agit pas d'une préoccupation particulièrement futile. De façon étonnante, Microsoft a un jour obtenu d'un tribunal qu'il prenne le contrôle opérationnel du domaine no-ip.org - c'est-à-dire qu'il détourne réellement le domaine - un service DNS dynamique utilisé par d'innombrables personnes - simplement parce qu'un utilisateur l'utilisait apparemment à des fins liées à des logiciels malveillants).
Les abonnés qui souhaitent limiter les ensembles de méthodes de validation du contrôle du domaine (c'est-à-dire DNS-01, HTTP-01 et/ou TLS-ALPN-01) qui peuvent être utilisés pour démontrer le contrôle de leur nom de domaine peuvent inclure ces méthodes dans le paramètre "validationmethods" de leurs enregistrements CAA.
L'enregistrement DNS CAA (Certification Authority Authorization) permet à un domaine de communiquer sa politique de délivrance aux autorités de certification. Elle permet seulement à un domaine de définir une politique avec une granularité de niveau CA. Cependant, la spécification CAA fournit également des facilités d'extension pour admettre une politique plus granulaire, spécifique à la CA. Cette spécification définit deux paramètres de ce type, l'un permettant à une CA d'être identifiés par URI (Uniform Resource Identifier) et un autre permettant des méthodes spécifiques de validation de contrôle de domaine telles que définies par le protocole ACME
Le protocole ACME (Automatic Certificate Management Environment) est un protocole de communication pour l'automatisation des échanges entre les autorités de certification et les propriétaires de serveur web, permettant le déploiement automatisé d’une infrastructure à clé publique à très bas coût. Il a été conçu par l’ISRG pour. Le protocole se base sur la transmission HTTPS de message JSON. Il a été publié comme standard Internet par l’IETF. L'ISRG fournit deux logiciels de référence gratuits et libres mettant en œuvre son protocole : certbot, un gestionnaire de certificats pour serveur web écrit en Python et boulder, une autorité de certification écrite en Go.
Les abonnés qui souhaitent limiter l'émission à un compte ACME spécifique peuvent inclure l'URL unique de ce compte (tel que renvoyé par le point de terminaison new-account avec onlyReturnExisting set 54) dans le paramètre "accounturi" de leurs enregistrements CAA.
Ces fonctionnalités ont été activées dans Staging depuis un certain temps (plus d'un an). Nous ne nous attendons pas à ce que l'activation de ces fonctionnalités en production entraîne des défaillances. Si vous observez des défaillances inattendues, veuillez vérifier à nouveau vos enregistrements CAA. Si cela ne résout pas votre problème, veuillez, comme toujours, poster un message dans la catégorie Aide de ce forum.
Source : Let's Encrypt team
Et vous ?
Quel est vote avis sur le sujet ? Avez-vous une expérience avec Let's encrypt ? Qu'en pensez-vous ?Voir aussi :
Les sites WordPress seraient piratés dans les secondes qui suivent l'émission des certificats TLS, les cybercriminels utilisent abusivement le protocole Certificate Transparency proposé par Google Caddy, l'unique serveur web à utiliser HTTPS automatiquement et par défaut, écrit en langage Go 
