J'ai regardé s'il y avait moyen d'ajouter du debug à lego/ovh, je n'ai rien vu. Idem pour la lib go-ovh, pas de bol que les logs ne soient pas hyper instructifs...
Vu qu'il y a exactement 10 minutes entre la fin du délais et la fin du check, ça ressemble à un time-out. Ça n'est pas clair si lego essaye de terminer la commande même si la vérification ne passe pas. À la vue de ton log, je dirais qu'il n'essaye même pas de terminer la commande. Essaye d'utiliser lego directement ( https://go-acme.github.io/lego/usage/cli/ ) , essaye aussi d'augmenter ton delais avant d'entamer la période de check. Qui sait? Pour être sûr, continue à lire ;)
Essaye de mesurer le temps de réplication DNS toi même. Fais un changement avec ton code php ou la web-if (pour etre sûr), ensuite tu check combien de temps ça met (dig @ns _acme-challenge.xxx.xx txt). Vérifie bien tous les différents NS, commence par essayer de trouver le master ovh, puis les réplicas ovh (=> teste tous les NS de la SOA), ensuite localement dans ton docker! Dis-toi bien que LE va utiliser les NS de ta zone (in fine), mais il ne va peut-être pas utilisé le "master" à jour. En d'autres mots, il se peut que la vérif locale fonctionne (tu as du bol, ton résolveur tombe sur le réplica à jour) mais que LE n'y arrive pas. Inversément, il se peut que ça ne fonctionne pas chez toi (genre un dns docker ou dans ton lan qui cache trop longtemps? -> pense aussi à réduire le ttl) alors que le record est bel et bien publié, ce qui fait que lego n'essaye pas de terminer la commande.
Idées: regarde s'il y a un réglage pour désactiver la vérification de lego, et base toi sûr le délais uniquement (pas top qd même), regarde si tu peux forcer le dns que lego utilise pour la vérification et utilise un dns public style google, voir ceux ovh directement.
Perso, j'utilise uacme avec de la glue custom (btw, je ne comprends pas pourquoi lego n'a juste pas un provider "shell" où tu peux scripter ce que tu veux... c'est tellement plus facile à débugger. Il faut croire que go is the new shell :'(). Aussi, vu que les secondaires de ma zone durent très très longtemps à se synchroniser, j'utilise des cname sur le _acme-challenge qui pointent dans une autre zone qui n'a qu'un seul NS que je controle directement avec ma glue. Tu peux essayer ça aussi, avec un cname qui pointe vers une zone contrôlé par un autre provider dns, genre un qui a l'air de mieux fonctionner avec traefik/lego. Éventuellement, regarde les différents github des providers legos, ça en dit surement quelque chose sur la qualité du truc (genre essaye de trouver un provider qui logge ce qu'il fait... genre pas ovh quoi :p ca coûtera tjrs moins cher qu'un certificat commercial) :D
[^] # Re: utiliser une machine qui a acces à internet
Posté par benja . En réponse au message Traefik et tls pour réseau local. Évalué à 2.
J'ai regardé s'il y avait moyen d'ajouter du debug à lego/ovh, je n'ai rien vu. Idem pour la lib go-ovh, pas de bol que les logs ne soient pas hyper instructifs...
Vu qu'il y a exactement 10 minutes entre la fin du délais et la fin du check, ça ressemble à un time-out. Ça n'est pas clair si lego essaye de terminer la commande même si la vérification ne passe pas. À la vue de ton log, je dirais qu'il n'essaye même pas de terminer la commande. Essaye d'utiliser lego directement ( https://go-acme.github.io/lego/usage/cli/ ) , essaye aussi d'augmenter ton delais avant d'entamer la période de check. Qui sait? Pour être sûr, continue à lire ;)
Essaye de mesurer le temps de réplication DNS toi même. Fais un changement avec ton code php ou la web-if (pour etre sûr), ensuite tu check combien de temps ça met (dig @ns _acme-challenge.xxx.xx txt). Vérifie bien tous les différents NS, commence par essayer de trouver le master ovh, puis les réplicas ovh (=> teste tous les NS de la SOA), ensuite localement dans ton docker! Dis-toi bien que LE va utiliser les NS de ta zone (in fine), mais il ne va peut-être pas utilisé le "master" à jour. En d'autres mots, il se peut que la vérif locale fonctionne (tu as du bol, ton résolveur tombe sur le réplica à jour) mais que LE n'y arrive pas. Inversément, il se peut que ça ne fonctionne pas chez toi (genre un dns docker ou dans ton lan qui cache trop longtemps? -> pense aussi à réduire le ttl) alors que le record est bel et bien publié, ce qui fait que lego n'essaye pas de terminer la commande.
Idées: regarde s'il y a un réglage pour désactiver la vérification de lego, et base toi sûr le délais uniquement (pas top qd même), regarde si tu peux forcer le dns que lego utilise pour la vérification et utilise un dns public style google, voir ceux ovh directement.
Perso, j'utilise uacme avec de la glue custom (btw, je ne comprends pas pourquoi lego n'a juste pas un provider "shell" où tu peux scripter ce que tu veux... c'est tellement plus facile à débugger. Il faut croire que go is the new shell :'(). Aussi, vu que les secondaires de ma zone durent très très longtemps à se synchroniser, j'utilise des cname sur le _acme-challenge qui pointent dans une autre zone qui n'a qu'un seul NS que je controle directement avec ma glue. Tu peux essayer ça aussi, avec un cname qui pointe vers une zone contrôlé par un autre provider dns, genre un qui a l'air de mieux fonctionner avec traefik/lego. Éventuellement, regarde les différents github des providers legos, ça en dit surement quelque chose sur la qualité du truc (genre essaye de trouver un provider qui logge ce qu'il fait... genre pas ovh quoi :p ca coûtera tjrs moins cher qu'un certificat commercial) :D