Aller au contenu principal

4. Vue d'ensemble du protocole

ACME permet aux clients de demander des opérations de gestion de certificats à l'aide d'un ensemble de messages JSON (JavaScript Object Notation) [RFC8259] transmis via HTTPS [RFC2818]. Le processus de délivrance avec ACME est similaire à celui d'une CA traditionnelle, où l'utilisateur crée un compte, demande un certificat et prouve son contrôle sur les noms de domaine figurant dans ce certificat, afin que la CA délivre le certificat demandé.

La première phase d'ACME consiste pour le client à demander un compte auprès du serveur ACME. Le client génère une paire de clés asymétriques et demande un nouveau compte, en fournissant optionnellement des informations de contact, en acceptant les conditions d'utilisation (Terms of Service, ToS), et/ou en associant le compte à un compte existant dans un autre système. La demande de création est signée avec la clé privée générée, pour prouver que le client la contrôle.

Client                                                   Server

[Contact Information]
[ToS Agreement]
[Additional Data]
Signature ------->
Account URL
<------- Account Object


[] Information covered by request signatures

Account Creation

Une fois l'enregistrement du compte effectué, le client doit accomplir quatre étapes principales pour obtenir un certificat :

  1. Soumettre une commande (Order) de délivrance de certificat

  2. Prouver le contrôle de tout identifiant (Identifier) demandé dans le certificat

  3. Finaliser la commande en soumettant une CSR

  4. Attendre la délivrance et télécharger le certificat délivré

La commande de certificat du client décrit les identifiants souhaités ainsi que quelques champs supplémentaires capturant des sémantiques non supportées par le format CSR. Si le serveur est prêt à envisager la délivrance d'un tel certificat, il répond avec une liste d'exigences que le client DOIT satisfaire avant que le certificat puisse être délivré.

Par exemple, dans la plupart des cas, le serveur exigera que le client prouve qu'il contrôle les identifiants dans le certificat demandé. Comme il existe de nombreuses façons différentes de valider la propriété de différents types d'identifiants, le serveur choisira parmi un ensemble extensible de défis adaptés aux identifiants déclarés. Le client utilise un ensemble de réponses pour indiquer au serveur quels défis il a accomplis. Le serveur vérifie ensuite que le client a bien accompli les défis.

Une fois le processus de validation terminé et le serveur satisfait que le client a rempli ses exigences, le client finalise la commande en soumettant une demande de signature de certificat (Certificate Signing Request, CSR) PKCS#10. Le serveur délivrera le certificat demandé et le mettra à disposition du client.

Client                                                   Server

[Order]
Signature ------->
<------- Required Authorizations

[Responses]
Signature ------->

<~~~~~~~~Validation~~~~~~~~>

[CSR]
Signature ------->
<------- Acknowledgement

<~~~~~~Await issuance~~~~~~>

[POST-as-GET request]
Signature ------->
<------- Certificate

[] Information covered by request signatures

Certificate Issuance

Pour révoquer un certificat, le client envoie une demande de révocation signée indiquant le certificat à révoquer :

Client                                                 Server

[Revocation request]
Signature -------->

<-------- Result

[] Information covered by request signatures

Certificate Revocation

Notez que, bien qu'ACME soit défini de manière suffisamment flexible pour gérer différents types d'identifiants, le cas d'utilisation principal traité dans ce document est celui où des noms de domaine sont utilisés comme identifiants. Par exemple, tous les défis de validation d'identifiants décrits à la section 8 concernent la validation de noms de domaine. L'utilisation d'ACME pour d'autres identifiants nécessitera des spécifications supplémentaires décrivant comment encoder ces identifiants dans le protocole et quels types de défis de validation le serveur pourrait exiger.