« Protocole ACME » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 1 : | Ligne 1 : | ||
[https://www.thesslstore.com/blog/acme-protocol-what-it-is-and-how-it-works/ Source] | [https://www.thesslstore.com/blog/acme-protocol-what-it-is-and-how-it-works/ 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). | 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. | 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. | 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: | Les étapes: | ||
* L'agent génère un CSR pour le domaine. | * L'agent génère un CSR pour le domaine. | ||
Ligne 20 : | Ligne 20 : | ||
L'agent peut être configuré afin de pinger le CA à intervalles réguliers, pour faire tourner les clefs ou remplacer tous les certifs. | 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: | Étapes: | ||
* L'agent génère une demande de révocation pour le certificat. | * L'agent génère une demande de révocation pour le certificat. | ||
Ligne 28 : | Ligne 28 : | ||
* Le statut révoqué du certificat est publié auprès des CRLs et OCSP. | * Le statut révoqué du certificat est publié auprès des CRLs et OCSP. | ||
== CRL / OCSP == | |||
CRL : Certificate Revocation List | CRL : Certificate Revocation List | ||
RFC 5280 et 6818 | RFC 5280 et 6818 | ||
Ligne 36 : | Ligne 36 : | ||
Alternative aux CRL (qui ont un temps de propagation gênant). Protocole utilisé pour valider un certificat x509. | 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: | 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: | ||
Ligne 58 : | Ligne 58 : | ||
* L'agent est en place. On peut alors configurer sa fréquence de renouvellement, etc. | * 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: | 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: | urn:ietf:params:acme:error: |
Version du 17 février 2021 à 15:58
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: