1. Introduction

Les certificats dans la Web PKI (Infrastructure à Clé Publique du Web) [RFC5280] sont le plus souvent utilisés pour authentifier des noms de domaine (Domain Names). Par conséquent, les autorités de certification (Certification Authorities, CAs) de la Web PKI sont approuvées pour vérifier que les demandeurs de certificats représentent légitimement les noms de domaine figurant dans ces certificats.

Différents types de certificats reflètent différents niveaux de vérification par la CA des informations sur le sujet du certificat. Les certificats à « validation de domaine » (Domain Validation, DV) sont de loin le type le plus courant. Dans le processus de délivrance d'un certificat DV, la seule vérification que la CA doit effectuer est de confirmer que le demandeur contrôle effectivement le nom de domaine [CABFBR]. La CA n'est pas tenue de tenter de vérifier l'identité réelle du demandeur. (Cela contraste avec les certificats à « validation d'organisation » (Organization Validation, OV) et à « validation étendue » (Extended Validation, EV), dont le processus vise également à vérifier l'identité réelle du demandeur.)

Les autorités de certification de la Web PKI existantes ont tendance à utiliser un ensemble de protocoles ad hoc (Ad Hoc Protocols) pour la délivrance de certificats et la vérification d'identité. Pour les certificats DV, l'expérience utilisateur typique est la suivante :

Générer une demande de signature de certificat (Certificate Signing Request, CSR) PKCS#10 [RFC2986].
Copier-coller la CSR dans la page Web de la CA.
Prouver la propriété du nom de domaine dans la CSR par l'une des méthodes suivantes :
- Placer un défi (Challenge) fourni par la CA à un emplacement spécifique sur le serveur Web.
- Placer un défi fourni par la CA dans un enregistrement DNS correspondant au domaine cible.
- Recevoir un défi fourni par la CA à une adresse e-mail (de préférence contrôlée par l'administrateur) correspondant au nom de domaine, puis répondre sur la page Web de la CA.
Télécharger le certificat délivré et l'installer sur le serveur Web de l'utilisateur.

À l'exception de la CSR elle-même et du certificat délivré, il s'agit de procédures entièrement ad hoc, accomplies en demandant à des utilisateurs humains de suivre les instructions en langage naturel de la CA, plutôt que par des protocoles publiés et implémentés par des machines. Dans de nombreux cas, ces instructions sont difficiles à suivre et entraînent une frustration et une confusion considérables. Des tests d'utilisabilité informels menés par les auteurs indiquent que les administrateurs de sites Web ont généralement besoin de 1 à 3 heures pour obtenir et installer un certificat pour un nom de domaine. Même dans le meilleur des cas, l'absence de mécanisme standardisé et publié entrave le déploiement généralisé de HTTPS et d'autres systèmes reposant sur PKIX, car cela inhibe la mécanisation des tâches liées à la délivrance, au déploiement et à la révocation des certificats.

Ce document décrit un cadre extensible pour automatiser le processus de délivrance de certificats et de validation de domaine, permettant ainsi aux serveurs et aux logiciels d'infrastructure d'obtenir des certificats sans intervention humaine. L'utilisation de ce protocole devrait considérablement simplifier le déploiement de HTTPS, ainsi que l'utilité de l'authentification basée sur PKIX dans d'autres protocoles basés sur TLS (Transport Layer Security) [RFC8446].

Il convient de noter que, bien que ce document se concentre sur la validation des noms de domaine pour la délivrance de certificats dans la Web PKI, ACME prend en charge des extensions permettant l'utilisation d'autres identifiants dans d'autres contextes PKI. Par exemple, au moment de la rédaction de ce document, des travaux sont en cours pour utiliser ACME afin de délivrer des certificats Web PKI attestant des adresses IP [ACME-IP] et des certificats STIR (Secure Telephone Identity Revisited) attestant des numéros de téléphone [ACME-TELEPHONE].

ACME peut également être utilisé pour automatiser certains aspects de la gestion des certificats, même dans les cas où des processus non automatisés sont encore nécessaires. Par exemple, la fonctionnalité de liaison de compte externe (External Account Binding) (voir section 7.3.4) peut permettre à un compte ACME d'utiliser des autorisations accordées à un compte externe non-ACME. Cela permet à ACME de gérer des scénarios de délivrance qui ne peuvent pas encore être entièrement automatisés, comme la délivrance de certificats à « validation étendue ».