Qu'est-ce que c'est ?

ACME signifie Automated Certificate Management Environment. Il a été développé par l'ISRG (Internet Security Research Group) pour son CA Let's Encrypt. Ce protocole permet à l'origine à Let's Encrypt de de générer des certifs renouvelables de 90 jours. Ce protocole est standard depuis peu (RFC 8555).

Principe de validation

ACME fonctionne par l'entremise d'un agent de gestion de certificats sur le serveur web. L'organisation / le domaine passe une validation lors de la mise en place, et une fois validé, il peut générer les certificats, les renouveler, les révoquer.

Le principe est que lors de la validation initiale, l'agent génère une paire de clefs (souvent appellées authorization keys) et et la partage avec la CA. Une fois que l'agent est validé et qu'on sait qu'il est bien légitime en tant que propriétaire de cette paire de clefs, il peut utiliser sa clef pour signer les CSR qu'il génère et envoie en https au CA. Le CA utilise le CSR et la clef publique associée pour générer le certificat et le renvoyer à l'agent. Tout ça peut être automatisé, bien sûr.

Fonctionnement du protocole (explication simple)

Génération / Renouvellement

Les étapes:

L'agent génère un CSR pour le domaine.
L'agent signe la clef publique générée avec le CSR avec la clef privée correspondante.
L'agent signe tout le CSR avec son AK (Activation Key) privée.
Le CA vérifie les deux signatures et génère le certificat.
L'agent reçoit le certificat et le met en place.

L'agent peut être configuré afin de pinger le CA à intervalles réguliers, pour faire tourner les clefs ou remplacer tous les certifs.

Révocation

Étapes:

L'agent génère une demande de révocation pour le certificat.
L'agent signe la requête avec son AK privée.
Le CA vérifie la signature.
Le CA révoque le certificat.
Le statut révoqué du certificat est publié auprès des CRLs et OCSP.

CRL / OCSP

CRL : Certificate Revocation List RFC 5280 et 6818 Liste signée par l'autorité de certification contenant tous les certificats révoqués. OCSP : Online Certificate Status Protocol RFC 6960 Alternative aux CRL (qui ont un temps de propagation gênant). Protocole utilisé pour valider un certificat x509.

Mise en place d'ACME

Il y'a des douzaines de clients (clients == agents) sur un tas de langages; ACME est open source. Le protocole permet de choisir son agent et ses CAs, pour peu d'avoir des CAs qui le supportent. Le protocole est actuellement en v2 et n'est PAs rétro-compatible. La v2 ajoute la possibilité de créer des wildcards. Une petite liste d'agents:

Certbot
ACMESharp
acme-client
GetSSL
Posh-ACME
Caddy
Sewer
nginx ACME
node-acme-lambda
peter_sslers

Une fois l'agent installé, il va en gros se passer ça:

Le client va demander quels domaines il va devoir gérer
Le client va offrir une liste de CA qui supportent ACME
Une fois le CA choisi, le client le contacte et génère sa paire de clefs
Le CA va générer un challenge DNS ou HTTPS qui va demander à l'agent de montrer qu'il a bien le contrôle sur le /les domaines.
En plus des challenges, le CA va envoyer un nonce que l'agent devra signer avec son AK privée, pour montrer qu'il contrôle bien ces clefs.
L'agent est en place. On peut alors configurer sa fréquence de renouvellement, etc.

Erreurs ACME courantes

Le protocole ACME utilise un format d'erreur standardisé (RFC 7807), et dans son champ type il met une série de tokens décrivant le problème. Cela ressemble à ça:

urn:ietf:params:acme:error:

Protocole ACME

Sommaire