Protocole ACME

Source

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:

Ici, on va se concentrer sur le token "error". Voici une liste des erreurs:

<source> Type Description accountDoesNotExist The requested account does not exist alreadyRevoked The requested certificate has already been revoked badCSR The CSR was generated incorrectly (non-compliant) badNonce The nonce generated was insufficient badPublicKey The server doesn’t support the public key that signed this badRevocationReason The requested revocation lacks a valid reason badSignatureAlgorithm The server doesn’t support the algorithm that was used to sign this caa Issuance forbidden by a CAA record compound Specific error conditions are indicated in the “subproblems” array connection The server couldn’t connect to the validation target dns There was a problem with the DNS query during validation externalAccountRequired The request is missing a value in the “externalAccountBinding” field incorrectResponse The client returned and incorrect response to a validation challenge invalidContact A contact URL for your account was invalid malformed The request message was malformed orderNotReady Self-explanatory rateLimited The request exceeds a rate limit rejectedIdentifier The server will not issue certificates for this domain serverInternal The server experienced an internal error tls A TLS error occurred during validation unauthorized The client isn’t authorized to make this request unsupportedContact A contact URL for your account used an unsupported protocol scheme unsupportedIdentifier Self-explanatory userActionRequired Manual intervention is required at the “instance” URL </source>

Challenges ACME

La validation est une des parties les plus complexes. Aujourd'hui, deux types de challenges sont principalement utilisés.

HTTP

Le CA envoie à l'agent un token à installer sur le serveur. L'agent créé un fichier qui contient le token ainsi qu'une empreinte de l'AK utilisées pour la mise en place. Les deux sont concaténées:

(Token) || '.' || (Thumbprint of Authorization Key)

Une fois fait, l'agent en informe le CA qui essaye de récupérer cette page web.

DNS

Ce challenge requiert que l'agent place une valeur TXT dans le DNS du domaine. Pareil, ce txt va contenir un token généré par le CA ainsi qu'une empreinte de l'AK; le tout est placé dans l'enregistrement TXT. Une fois fait, le CA essaye de récupérer ledit enregistrement.

Recommandations

Les challenges ne devraient pas prendre trop longtemps (environ 15 secondes). La RFC fait quelques suggestions :

• Les clients ne devraient pas répondre aux challenges tant qu'ils ne sont pas sûrs que les requêtes au serveur vont aboutir.
• L'agent peut rééssayer en cas d'échec, mais pas plus d'une fois toutes les 5 à 10 secondes.
• Il peut y avoir un délai entre le moment ou le fichier / enregistrement TXT est en ligne et le moment ou le CA peut les récupérer.

ACME ne fait pas que des certificats DV

Même si c'est en général à ça qu'il sert. Mais il peut être utilisé pour récupérer des certificats à haute valeur aussi. Il faut alors un lien commercial avec la CA. Le protocole fait alors la même chose, mais deux autres choses se passent en parrallèle. En plus de contacter la CA, l'organisation va passer une validation valable 24 mois... Mais tout ça ne concerne pas notre agent, qui se contentera de demander ses certificats (albeit en fournissant sans doute un login et un mot de passe au préalable).

EAB : External Account Binding

Source

Certaines autorités de certification, comme ZeroSSL ou Sectigo, utilisent un système de gestion de comptes qui est séparé des comptes ACME (donc, on a un compte utilisateur du type login / password). Du coup, pour pouvoir créer des certificats via le protocole ACME, il faut fournir des informations supplémentaires qui vont lier le compte ACME au compte externe : c'est l'EAB (External Account Binding).

Obtenir des credentials EAB

Dans ce genre de cas, il faut d'abord créer un compte utilisateur auprès de l'autorité de certification; ensuite, celle-ci doit disposer d'une interface quelconque permettant de d'y rattacher un compte ACME.

Les credentials EAB vont inclure au moins 2 valeurs:

• Une clef (**key**) ou **KeyID**, qui est simplement une chaîne de caractères.
• Une clef HMAC (ou juste HMAC) : une valeur en base64. Parfois, cette clef va également comporter un identifiant d'algo tel que HS256 ou "HMAC with SHA-256".

Ces credentials peuvent, en fonction de l'autorité de certification, servir à créer plusieurs compte ACME ou un seul.