Certificats à courte durée de vie et ACME ARI
Laissez la CA indiquer à chaque client ACME quand renouveler, et gardez un renouvellement fiable alors que la durée de vie des certificats TLS descend à 47 jours.
Le calendrier SC-081
Le ballot SC-081, adopté par le CA/Browser Forum en avril 2025, réduit la validité maximale des certificats TLS publiquement reconnus et la durée pendant laquelle une validation de domaine ou d'adresse IP peut être réutilisée :
| Certificats émis à partir du | Validité maximale | Réutilisation de la validation domaine / IP |
|---|---|---|
| Avant le 15 mars 2026 | 398 jours | 398 jours |
| 15 mars 2026 | 200 jours | 200 jours |
| 15 mars 2027 | 100 jours | 100 jours |
| 15 mars 2029 | 47 jours | 10 jours |
Les informations d'identité du sujet (données d'organisation des certificats OV / EV) peuvent être réutilisées pendant 398 jours à partir du 15 mars 2026.
Une CA privée exploitée dans DuoKey n'est pas soumise à ces règles, mais les clients et outils conçus pour le web public supposent de plus en plus des durées de vie courtes. Avec des certificats de 47 jours, un certificat est renouvelé environ chaque mois : le renouvellement doit être automatisé et son moment est mieux décidé par la CA.
ACME Renewal Information (ARI)
ARI (RFC 9773) permet à la CA d'indiquer à chaque client ACME quand renouveler un certificat donné, au lieu que chaque client applique une règle fixe comme « 30 jours avant expiration », inadaptée aux certificats de 47 ou 7 jours. Le serveur ACME DuoKey prend en charge ARI sur chaque répertoire de CA.
Répertoire et fenêtre de renouvellement
Le répertoire https://<cockpit>/api/pki/acme/<ca-id>/directory annonce une URL renewalInfo. Un client demande la fenêtre d'un certificat ainsi :
GET /api/pki/acme/<ca-id>/renewal-info/<certID>
HTTP/1.1 200 OK
Retry-After: 3600
Content-Type: application/json
{"suggestedWindow": {"start": "2026-10-19T16:00:00Z", "end": "2026-10-20T20:00:00Z"}}certID est l'Authority Key Identifier et le numéro de série du certificat en base64url (sans padding), séparés par un point, comme défini par la RFC 9773. Les certificats émis par le serveur ACME DuoKey portent un Authority Key Identifier à cet effet.
| Durée de vie du certificat | Fenêtre de renouvellement suggérée |
|---|---|
| Toute durée L | Des deux tiers aux cinq sixièmes de L (soit de notAfter - L/3 à notAfter - L/6) |
| 90 jours | Jours 60 à 75 |
| 47 jours | Jours 31,3 à 39,2 |
| 7 jours | Jours 4,7 à 5,8 |
Retry-After vaut 1 heure pour les certificats de 10 jours ou moins, 6 heures sinon. Un certificat inconnu répond 404, un certID mal formé 400.
Remplacer un certificat
Une nouvelle commande peut désigner le certificat qu'elle remplace avec "replaces": "<certID>". Le serveur vérifie que le certificat a été émis par le même répertoire ACME, au même compte ACME, partage au moins un identifiant avec la nouvelle commande et n'a pas déjà été remplacé par une autre commande (sinon 409 alreadyReplaced, y compris lorsque deux commandes sont simultanées).
Forcer un renouvellement anticipé
Après un incident (changement de clé de CA, émission erronée), un administrateur peut demander à tous les clients compatibles ARI d'un répertoire de renouveler immédiatement :
PUT /api/pki/acme/<ca-id>/ari-trigger
{"renew_issued_before": "2026-10-15T12:00:00Z"}Chaque certificat de ce répertoire émis avant cet instant reçoit une fenêtre de renouvellement déjà passée : les clients renouvellent à leur prochaine consultation ARI (dans le délai Retry-After). null efface le déclencheur ; GET le renvoie (Operations.Pki.Acme.Read). Les modifications sont enregistrées dans le journal d'audit.
Validité des certificats ACME
Les certificats ACME sont émis pour la validité maximale configurée sur le répertoire (1 à 3 650 jours ; 90 jours par défaut), raccourcie au notAfter de la commande lorsque le client demande une date plus proche, et jamais au-delà de l'expiration de la CA elle-même. Pour des certificats à courte durée de vie, réglez la validité maximale du répertoire en conséquence (par exemple 47 ou 7 jours).
Validation de domaine : http-01, dns-01, tls-alpn-01
Lorsqu'un client ACME répond à un challenge, le serveur ACME DuoKey vérifie lui-même le contrôle du domaine avant que la commande puisse être finalisée. Une CA interne sur un réseau de confiance peut à la place définir ACME_AUTO_VALIDATE=1, qui accepte chaque challenge sans vérification (comportement inchangé ; à ne pas utiliser lorsque les demandeurs ne sont pas de confiance).
Challenges proposés pour une commande
Chaque autorisation propose les types de challenge autorisés sur le répertoire ACME (allowed_challenge_types, dans cet ordre ; http-01 lorsque la CA n'a pas de configuration ACME), filtrés par identifiant :
| Identifiant | Types de challenge proposés |
|---|---|
example.com | Tous les types autorisés sur le répertoire |
*.example.com (wildcard) | dns-01 uniquement (RFC 8555 section 7.1.3). L'autorisation porte sur example.com avec "wildcard": true. Si le répertoire n'autorise pas dns-01, la nouvelle commande est refusée avec rejectedIdentifier |
| Adresse IP | http-01 uniquement (tls-alpn-01 pour les adresses IP, RFC 8738, n'est pas implémenté) |
Les identifiants DNS mal formés (a.*.example.com, *.*.example.com, labels vides) sont refusés avec rejectedIdentifier. Les jetons de challenge sont des valeurs aléatoires de 256 bits.
Règle de commande : toutes les autorisations doivent être valides
Une commande ne devient ready (et ne peut être finalisée) que lorsque toutes ses autorisations sont valides. Une commande pour example.com et *.example.com exige donc la réussite des deux challenges.
Un challenge en échec rend le challenge, son autorisation et la commande invalid (RFC 8555 section 7.1.6), avec un document de problème ACME (dns, connection, tls, incorrectResponse, rejectedIdentifier ou unauthorized). Le client crée alors une nouvelle commande. Un challenge parvenu à un état final n'est pas revalidé.
Les versions précédentes considéraient une commande à plusieurs identifiants comme prête dès qu'un seul challenge était validé. Un client qui ne répondait qu'à une partie des challenges doit désormais répondre à tous.
http-01
Le serveur récupère http://<domaine>/.well-known/acme-challenge/<jeton> et compare la réponse à la key authorization. C'est le type par défaut, et le seul disponible pour les identifiants de type adresse IP.
dns-01 (RFC 8555 section 8.4)
Le serveur lit les enregistrements TXT de _acme-challenge.<domaine> (pour *.example.com : _acme-challenge.example.com) et accepte le challenge si l'un d'eux vaut base64url(SHA-256(keyAuthorization)).
- Plusieurs enregistrements TXT peuvent coexister (par exemple le wildcard et le domaine de base d'une même commande, ou une ancienne valeur).
- Les CNAME sont suivis : la délégation de
_acme-challengevers une zone de validation dédiée fonctionne. - NXDOMAIN, une réponse vide ou un délai dépassé font échouer le challenge avec un problème
dns; des enregistrements sans la valeur attendue le font échouer avecincorrectResponse. - Aucune réponse DNS n'est mise en cache entre deux tentatives.
Utilisez dns-01 pour les certificats wildcard et pour les hôtes que le cockpit ne peut pas joindre sur les ports 80 ou 443.
Les clients ACME publient l'enregistrement TXT via le plugin de leur fournisseur DNS (solveur dns01 de cert-manager, certbot --preferred-challenges dns, lego --dns). L'enregistrement doit être visible depuis le résolveur utilisé par le cockpit avant que le client ne réponde au challenge ; avec un fournisseur DNS lent à propager, configurez le délai de propagation du client.
Résolveurs et DNS split-horizon
| Variable | Défaut | Signification |
|---|---|---|
ACME_DNS_RESOLVERS | (non définie) | Serveurs de noms séparés par des virgules, IP ou IP:port ([IPv6]:port en IPv6). Si elle est définie, les requêtes dns-01 ne vont qu'à ces serveurs |
ACME_DNS_TIMEOUT_SECS | 10 | Délai par requête DNS, de 1 à 60 secondes |
Sans ACME_DNS_RESOLVERS, les serveurs de noms du pod ou de l'hôte (/etc/resolv.conf) sont utilisés. En DNS split-horizon, lorsque le cockpit doit voir la vue interne d'une zone (ou la vue publique), faites pointer ACME_DNS_RESOLVERS vers le résolveur qui sert cette vue :
env:
- name: ACME_DNS_RESOLVERS
value: "10.20.0.53,10.20.0.54"
- name: ACME_DNS_TIMEOUT_SECS
value: "5"tls-alpn-01 (RFC 8737)
Le serveur résout le domaine, se connecte au port 443 en ne proposant que le protocole ALPN acme-tls/1 (SNI égal au domaine), et accepte le certificat auto-signé présenté si :
acme-tls/1a été négocié ;- son subjectAltName contient exactement une entrée, un nom DNS égal au domaine ;
- il porte l'extension critique
id-pe-acmeIdentifier(1.3.6.1.5.5.7.1.31) contenant le SHA-256 de la key authorization.
Le certificat est auto-signé par conception, aucune chaîne n'est donc validée, mais la signature de la poignée de main TLS est vérifiée : le pair détient la clé du certificat qu'il présente. Il n'y a pas de redirection ; chaque tentative de connexion expire après 10 secondes et au plus quatre adresses résolues sont essayées. Non disponible pour les identifiants wildcard ou IP.
Connexions sortantes
http-01 et tls-alpn-01 se connectent à une adresse dérivée de l'identifiant demandé. Si l'une des adresses résolues est de bouclage, link-local (y compris l'adresse de métadonnées cloud 169.254.169.254) ou non spécifiée, le challenge échoue avec rejectedIdentifier et aucune connexion n'est ouverte. Les adresses de réseau privé (RFC 1918, ULA IPv6) restent autorisées, car une CA interne valide des hôtes internes. La connexion vise l'adresse qui a été vérifiée : une seconde réponse DNS ne peut pas la rediriger. dns-01 n'interroge que les résolveurs configurés et ne se connecte jamais à une adresse tirée de l'identifiant.
Déclencheurs de renouvellement dans DuoKey
| Certificats | Ce qui déclenche le renouvellement |
|---|---|
| Émis par le serveur ACME DuoKey à des clients ACME (cert-manager, certbot, lego…) | Le client. Les clients compatibles ARI suivent suggestedWindow ; les autres appliquent leur propre règle (cert-manager : deux tiers de la durée de vie par défaut) |
| Émis par une CA DuoKey et déployés par Cockpit sur une cible | Les politiques de renouvellement : seuil plafonné à la moitié de la durée de vie, donc un certificat de 47 jours avec un seuil de 30 jours est renouvelé vers le 23e jour, et un certificat de 7 jours ne boucle pas |
| Tout certificat émis ou découvert | Les alertes d'expiration préviennent le tenant à ses seuils |
Préparation aux 47 jours
Prêt aujourd'hui
- ARI sur le serveur ACME intégré : informations de renouvellement,
replaces,alreadyReplaced, renouvellement forcé par l'administrateur. - La validité des certificats ACME suit la configuration du répertoire, jusqu'à un jour.
- Renouvellement côté serveur des certificats déployés, sans boucle sur les certificats à courte durée de vie, avec nouvelles tentatives, temporisation, alertes et renouvellement unique entre réplicas.
- Alertes d'expiration par tenant (e-mail, Teams, Slack, webhooks), une fois par seuil.
- Kubernetes cert-manager via le serveur ACME.
- Validation de domaine par
http-01,dns-01(y compris certificats wildcard et résolveurs split-horizon) ettls-alpn-01; une commande n'est prête que lorsque toutes ses autorisations sont valides.
Limites
- Aucune validation n'est réutilisée : chaque commande revalide, ce qui respecte par construction une limite de réutilisation de 10 jours (sans économiser de travail pour autant).
- La validation se fait depuis un seul point d'observation, de façon synchrone dans la requête de challenge. Il n'y a ni validation multi-perspective (exigée des CA publiques par le ballot SC-067 du CA/Browser Forum) ni vérification CAA. Cela convient à une CA privée ; ce n'est pas le profil de validation d'une CA publiquement reconnue.
tls-alpn-01pour les identifiants de type adresse IP (RFC 8738) n'est pas implémenté.- Les certificats émis via ACME sont conservés sur leur commande ACME : ils ne figurent pas encore dans l'inventaire des certificats émis et ne sont couverts ni par les alertes d'expiration ni par les politiques de renouvellement.
- La requête ACME
revoke-certest acceptée mais n'ajoute pas encore le certificat à la CRL ni aux réponses OCSP de la CA. Préférez une validité courte pour les certificats ACME afin de limiter l'exposition en cas de compromission. - Le client ACME de Cockpit (vers les CA publiques) ne lit pas l'ARI de ces CA.
- La charge concurrente n'est mesurée que sur une seule instance, avec des challenges validés automatiquement (voir Charge mesurée). Le débit sur plusieurs réplicas et avec une vraie validation
http-01/dns-01n'est pas mesuré. - Les routes publiques de protocole, ACME compris, sont limitées par défaut à 1000 requêtes par minute et par adresse source, ce qui plafonne une adresse à environ 100 certificats ACME par minute. Augmentez
DKE_PROTOCOL_RATE_LIMIT_PER_MIN(jusqu'à 100000) lorsqu'une flotte atteint Cockpit depuis une seule adresse de sortie, par exemple cert-manager dans un cluster derrière un NAT.
Charge mesurée
Un test de charge exerce le protocole ACME sur une instance Cockpit : N clients ACME, chacun avec son propre compte, s'exécutent en parallèle ; chaque client émet des certificats de 7 jours et renouvelle chacun juste après son émission (informations de renouvellement, puis nouvelle commande avec replaces, jusqu'à la finalisation et au téléchargement). Le débit compte les certificats émis et renouvelés sur la durée de la phase parallèle.
Exécutions du 24 octobre 2026, build release, CA ECDSA P-256, certificats de 7 jours, 40 connexions à la base, une exécution par ligne :
| Clients x certificats par client | Émis | Renouvelés | Erreurs | Durée | Certificats/s (émis + renouvelés) | Émission p50 / p95 / p99 | Renouvellement p50 / p95 / p99 |
|---|---|---|---|---|---|---|---|
| 1 x 200 | 200 | 200 | 0 | 45,1 s | 8,9 | 104 / 128 / 141 ms | 115 / 139 / 155 ms |
| 8 x 25 | 200 | 200 | 0 | 10,0 s | 39,9 | 188 / 212 / 264 ms | 205 / 236 / 244 ms |
| 8 x 100 | 800 | 800 | 0 | 41,0 s | 39,0 | 192 / 230 / 293 ms | 210 / 248 / 275 ms |
| 16 x 13 | 208 | 208 | 0 | 10,8 s | 38,5 | 355 / 732 / 802 ms | 410 / 563 / 588 ms |
| 32 x 7 | 224 | 224 | 0 | 8,4 s | 53,3 | 558 / 748 / 757 ms | 621 / 686 / 697 ms |
| 32 x 25 | 800 | 800 | 0 | 30,8 s | 52,0 | 570 / 695 / 727 ms | 640 / 727 / 736 ms |
| 64 x 4 | 256 | 256 | 0 | 9,9 s | 51,7 | 1,16 / 1,39 / 1,39 s | 1,27 / 1,29 / 1,30 s |
| 64 x 16 | 1024 | 1024 | 0 | 44,2 s | 46,3 | 1,32 / 1,56 / 1,58 s | 1,44 / 1,59 / 1,61 s |
Toutes les exécutions se sont terminées sans erreur. Le débit plafonne à environ 40 à 53 certificats par seconde à partir de 8 clients ; au-delà, des clients supplémentaires n'ajoutent que du temps d'attente. Les lignes de 10 secondes sont plus courtes et plus bruitées que celles de 30 à 45 secondes.
Conditions du test, à garder en tête pour lire ces chiffres :
- Une seule instance Cockpit, requêtes envoyées dans le processus (sans réseau ni TLS), PostgreSQL 16 dans Docker sur la même machine : un portable de développement (AMD Ryzen AI 9 HX PRO 370, 12 cœurs / 24 threads, 55,6 Go de RAM, Windows 11) sur lequel tournaient aussi un IDE et un navigateur.
- Les challenges étaient acceptés sans vérification (
ACME_AUTO_VALIDATE=1). En production, la validationhttp-01/dns-01(propagation DNS comprise) prend généralement plus de temps que l'émission elle-même. - La limite par adresse a été relevée à 100000 requêtes par minute pour le test. Avec la valeur par défaut (1000), l'exécution à un seul client a été arrêtée au bout d'environ 10 secondes.
- Le client de test demande un nouveau nonce avant chaque requête signée (10 requêtes par émission, 11 par renouvellement) ; les vrais clients ACME réutilisent le nonce de chaque réponse.
Lisez ces chiffres comme un ordre de grandeur, pas comme une garantie de capacité.