dns.certs.demander.validerLance l'obtention du certificat. La page attend la fin : comptez de quelques secondes à quelques minutes.
Voir l'élément dans l'écran : dns/certificates
Le Hub déroule tout l'échange ACME pendant que la page attend :
_acme-challenge.<nom> dans la zone, chez son fournisseur ;Le temps dépend surtout du fournisseur DNS : certains publient en quelques secondes, d'autres en plusieurs minutes.
POST /hub/dns/certs/request → acme_worker.request_certificate
| Paramètre | Obligatoire | Vient du champ | Remarque |
|---|---|---|---|
domain |
oui | Domaine | le nom à couvrir |
wildcard |
non | — (pas à l'écran) | "true" : couvre <domaine> et *.<domaine> en une seule commande |
| Cas | Message |
|---|---|
| succès | « Certificate requested for domaine. » |
| échec | « Failed to request certificate: Certificate request failed for domain: domaine » |
Le motif précis d'un échec (zone introuvable, défi refusé, adresse du compte ACME absente) n'est que dans le journal du Hub.
{ "name": "acme_worker__request_certificate",
"arguments": { "domain": "exemplia.example", "wildcard": "true" } }
Le Hub range alors le certificat deux fois dans Vault : sous *.exemplia.example et sous
exemplia.example.
soclehub.acme.account-email renseigné ;La liste et le champ libre portent tous deux name="domain". Le champ masqué par Alpine
(x-show) n'est pas désactivé : le navigateur envoie les deux valeurs, dont une vide. Spring
remet alors au contrôleur les deux valeurs jointes par une virgule (admin.exemplia.example,),
et la commande ACME porte sur un nom invalide. Par MCP, l'action reçoit un nom propre.
Si le TXT n'est pas visible à temps, le Hub tente quand même la validation : elle échoue alors chez Let's Encrypt, qui limite le nombre d'échecs par heure et par compte.