Lua-resty-auto-ssl: Certificats génériques

Je ne suis pas responsable du dépôt mais je dois dire que ce n'est pas quelque chose de facile à ajouter. Les certificats génériques LE nécessiteront une validation DNS, et actuellement lua-resty-auto-ssl utilise la validation http.

La validation DNS serait bien d'avoir, même sans tenir compte des caractères génériques. Quelques réflexions :

• nous devons d'abord attendre déshydraté pour obtenir le support ACMEv2 : déshydraté # 420
• dehydrated prend déjà en charge le challenge (ACMEv1) dns-01 . Le défi dns-01 dans le brouillon ACMEv2 actuel me semble identique ou presque identique.
• le crochet deploy_challenge de déshydraté fournit un domaine et un jeton à écrire dans un enregistrement TXT.
• puisque nous ne savons pas comment les utilisateurs gèrent leurs enregistrements DNS, cette partie doit être générique.
  
  
  
  1. prend en charge les API DNS populaires. Nous devrions au moins ajouter une infrastructure pour supporter les API "standard" comme celle fournie par PowerDNS, CloudFlare ou même nsupdate. Dans ce cas, seule une sorte de jeton d'authentification est nécessaire dans nos paramètres.
  
  
  2. Les utilisateurs incontournables auront besoin d'une solution personnalisée pour définir ces enregistrements, comme parler à une API propriétaire ou même appeler des scripts shell sales. Nous devrions fournir un crochet générique pour ces cas :
     
     -- Define a function to store the validation tokens for DNS verification -- by let's encrypt in your DNS setup. auto_ssl:set("deploy_dns_challenge", function(domain, token) -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token end)
  
  
• la couche de stockage suppose actuellement qu'elle peut utiliser le domaine complet comme clé pour obtenir le certificat. Cela ne sera plus vrai. Ma première idée est de stocker les caractères génériques sous la forme parentdomain.com:wildcard:latest et de faire en sorte que la couche de stockage vérifie cette clé si un certificat concret n'est pas trouvé.

Des questions:

1. comment savoir s'il faut générer un certificat normal ou générique ? une nouvelle fonction définie par l'utilisateur is_wildcard_domain ? Une nouvelle valeur de retour pour le allow_domain ?
2. prenons-nous en charge la validation DNS (pour les caractères génériques) et HTTP (pour les certificats normaux) en même temps, ou uniquement DNS pour les deux ? Notez que HTTP peut être beaucoup plus rapide, puisque nous contrôlons toutes les pièces mobiles.

Pour votre information : un point de terminaison de staging ACMEv2 est désormais disponible. :)

Le défi dns-01 dans le brouillon ACMEv2 actuel me semble identique ou presque identique.

Vous avez raison :-) Rien n'a changé dans le challenge DNS-01 entre les API V1 et V2.

Pour votre information : au moins la version de développement de Dehydrated prend désormais en charge ACMEv2 ainsi que les certificats génériques. Au cas où quelqu'un voudrait commencer à travailler dessus, c'est maintenant votre chance ;)

Je pense que resty-auto-ssl faisant la validation DNS est complètement hors de portée.
Cependant, il devrait nous être possible de faire en sorte que resty-auto-ssl se replie sur un certificat générique configuré "hors bande".
Par exemple, je vais configurer mon service en utilisant bind9 et certbot pour créer un certificat générique pour un domaine. Pour le moment, je ne pense pas pouvoir dire à resty-auto-ssl d'utiliser ce certificat générique au lieu d'essayer d'en générer un.

EDIT: eh bien, ce n'est pas si hors de portée. Je ne savais pas que déshydraté pouvait être configuré avec des scripts manuels pour se connecter à une API DNS personnalisée...

Existe-t-il un moyen de stocker un certificat LE générique généré manuellement dans Redis afin que resty-auto-ssl puisse l'utiliser ?

D'après ce que je comprends du code, ce n'est pas possible. Nous pourrions facilement ajouter les vérifications suivantes dans l'interface de stockage, pour chaque sub.domain.tld :

• sub.domain.tld:latest — courant
• *.domain.tld:latest
• *.sub.domain.tld:latest

De cette façon, nous pourrions faire un premier pas vers les caractères génériques, ne prenant en charge que les certificats générés précédemment pour l'instant. Après cela, nous pourrions passer à autre chose et décider d'une manière agréable de prendre en charge la génération de certificats génériques, si nous décidons de le faire.

Edit : Je serais heureux de gratter une implémentation de ce qui précède.

@akalipetis avez-vous essayé de voir si le réglage

ssl_options.fullchain_der
ssl_options.privkey_der

fonctionnerait dans allow_domain ?
Si c'est possible, vous pouvez faire une requête redis dans allow_domain et les définir.

Pour mémoire, je viens de rencontrer ce problème, j'utilise lua-resty-auto-ssl pour générer des certificats pour les pages d'état de domaine personnalisées sur mon service de surveillance et la plupart des gens utiliseraient mes propres domaines comme xxxx.status.updown.io pour lesquels c'est beaucoup plus efficace pour utiliser un certificat générique.

J'y suis parvenu en utilisant le lambda allow_domain pour ignorer la génération de certificats pour *status.updown.io :

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

Et ensuite fourni le caractère générique comme certificat de secours par défaut :

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

J'ai généré le certificat manuellement en utilisant le défi DNS avec :

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

Je ne suis pas sûr que cela vaille la peine de passer mon temps à automatiser cela car cela semble compliqué avec le défi DNS. C'est low tech mais ça marche comme prévu :)

C'est une bonne solution de contournement, et qui s'applique à de nombreux cas d'utilisation.
Cependant, sachez que le défi DNS a été rendu très facile avec https://github.com/AnalogJ/lexicon !
Il fonctionne bien et prend en charge de nombreux fournisseurs. J'en ai même ajouté un et le processus est ridiculement facile.

@kapouer merci pour le conseil sur lexicon , je le garderai à l'esprit si je veux automatiser ;)

Pour mémoire, je viens de rencontrer ce problème, j'utilise lua-resty-auto-ssl pour générer des certificats pour les pages d'état de domaine personnalisées sur mon service de surveillance et la plupart des gens utiliseraient mes propres domaines comme xxxx.status.updown.io pour lesquels c'est beaucoup plus efficace pour utiliser un certificat générique.

J'y suis parvenu en utilisant le lambda allow_domain pour ignorer la génération de certificats pour *status.updown.io :

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

Et ensuite fourni le caractère générique comme certificat de secours par défaut :

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

J'ai généré le certificat manuellement en utilisant le défi DNS avec :

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

Je ne suis pas sûr que cela vaille la peine de passer mon temps à automatiser cela car cela semble compliqué avec le défi DNS. C'est low tech mais ça marche comme prévu :)

Je fais également le même type de vérification de domaine pour notre application. Si l'hôte du portail de l'utilisateur contient l'un de nos "propres" domaines, nous revenons simplement à l'utilisation de certificats génériques d'une autorité de certification statique. Mais j'aime votre idée de toujours utiliser LE et de générer les caractères génériques manuellement.

Je vais tester ça.

Mettre à jour
D'accord, c'est la solution qui fait vraiment ce que je veux. Le plug-in cloudflare. Les docs sont plutôt bien. Je l'ai fait fonctionner en une heure ou deux.

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

@jarthod une autre solution de contournement pour automatiser cela ? Se souvenir de renouveler le joker tous les 3 mois est en fait pénible.

@jarthod une autre solution de contournement pour automatiser cela ? Se souvenir de renouveler le joker tous les 3 mois est en fait pénible.

Pas de mon côté, je l'utilise toujours et je renouvelle le manuel tous les 3 mois. La mémorisation n'est pas un problème pour moi car j'utilise mon service (updown.io) pour surveiller le point de terminaison et il m'alerte lorsque le certificat est sur le point d'expirer.

Je suis également utilisateur de votre service. Quoi qu'il en soit, je suis allé de l'avant et j'ai obtenu le SSL générique traditionnel d'un an.

Maintenant votre service a du boulot pour me rappeler l'année prochaine 😄

Le 03-oct-2020, à 22h30, Adrien Rey-Jarthon [email protected] a écrit :

En tant que
@jarthod une autre solution de contournement pour automatiser cela ? Se souvenir de renouveler le joker tous les 3 mois est en fait pénible.

Pas de mon côté, je l'utilise toujours et je renouvelle le manuel tous les 3 mois. La mémorisation n'est pas un problème pour moi car j'utilise mon service (updown.io) pour surveiller le point de terminaison et il m'alerte lorsque le certificat est sur le point d'expirer.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désabonnez-vous.