Forum Linux.debian/ubuntu Génération certificats avec bind9 via RFC2136

Posté par  . Licence CC By‑SA.
Étiquettes :
0
22
juin
2022

Bonsoir,

Depuis quelque temps j'utilise certbot avec nginx.

De cette façon, je générais mes certificats.

J'aimerais me lancer dans la génération de certificats via RFC2136 pour me soustraire de la contrainte certbot via nginx.

Mon système est sous debian bullseye avec comme serveur DNS bind9 déjà configuré pour mon utilisation.

Est-ce que c'est faisable avec bind9 et auriez quelques étapes à me donner ?

Merci à vous

  • # ports internes

    Posté par  . Évalué à 1.

    Est-ce que c'est faisable avec bind9

    Oui, c'est possible avec n'importe quel serveur dns du moment que c'est un serveur authoritaire d'une zone. Note que tu peux utiliser une zone différente du domaine de ton certificate en utilisant un cname (pour + de détails cf. la rfc de acme).

    et auriez quelques étapes à me donner ?

    Disons que ça dépend un peu de ton setup. Je fais ça avec uacme, des certificats ssh, un chouilla de shell, luajit+ffi et nsd—mais disons que c'est probablement overkill pour le quidam. Dans le repo du client uacme il y a un script de démonstration pour s'intégrer avec nsupdate aka ta rfc2136, je regarderais de ce côté si j'étais toi. J'imagine qu'avec certbot c'est possible aussi…

    • [^] # mauvais titre

      Posté par  . Évalué à 1.

      (je me suis emmêlé les pinceaux)

  • # regarder comme ca se passe

    Posté par  . Évalué à 3.

    le challenge DNS qui est ce que tu recherches j'imagine, consiste à mettre un enregistrement DNS particulier (TXT il me semble) qui t'es demandé par le client ACME

    il faut donc faire la manip en 2 etapes
    1°) executer la demande ACME
    2°) acme te repond de creer l'enregistrement fhdksqfhdsjqfhezgé1376823187312.domaine.tld
    3°) tu crees l'entrée DNS qui va bien
    4°) tu poursuis ou tu relances la demande
    5°) acme trouve l'entrée DNS et valide ton certificat

    • [^] # Re: regarder comme ca se passe

      Posté par  . Évalué à 1.

      Avec quelle commande tu effectue ces étapes ?

    • [^] # Re: regarder comme ca se passe

      Posté par  . Évalué à 1.

      le challenge DNS qui est ce que tu recherches j'imagine, consiste à mettre un enregistrement DNS particulier (TXT il me semble) qui t'es demandé par le client ACME

      Exactement, par contre dans mon cas c'est certbot qui fait la demande.

      Dans le log certbot, il y a ceci.

      certbot_dns_rfc2136._internal.dns_rfc2136:No authoritative SOA record found for _acme-challenge.subdomain.mondomain.fr
certbot_dns_rfc2136._internal.dns_rfc2136:No authoritative SOA record found for subdomain.mondomain.fr
certbot_dns_rfc2136._internal.dns_rfc2136:Received authoritative SOA response for mondomain.fr

      Je pense que certbot peut ajouter les entrées TXT qui vont bien mais n'es pas autorisé par bind9.

      • [^] # Re: regarder comme ca se passe

        Posté par  . Évalué à 1. Dernière modification le 23 juin 2022 à 13:48.

        Il manque visiblement un partie de ton log. Ce que tu vois c'est simplement certbot qui essaye (et réussi) à trouver le(s) bon(s) nameserver(s) autoritaire de la zone. En l'occurence cloudflare, et ça m'étonnerai que cloudflare propose le protocol nsupdate (mais je peux me tromper). donc où est passé ton bind? comme je te l'ai dit, tu peux éventuellement ajouter dans clouflare un _acme-challenge.subdomain CNAME vers un label dans une zone de ton ton bind, où bien ajouter un record NS pour subdomain.mondomain.fr qui pointe vers ton bind (btw, c'est curieux d'avoir enregistré ce nom :) Peut-être aussi que certbot peut utiliser l'api de clouflare directement, dans quel cas tu n'as pas besoin de bind.

        • [^] # Re: regarder comme ca se passe

          Posté par  . Évalué à 1.

          Voici le log entier.

          https://funambule.org/privatebin/?46c84815bec4dd21#3cEYcZDubFydT1bYf6D5d1uSQWAMD9jEkxRZEXKiFtD7

          • [^] # Re: regarder comme ca se passe

            Posté par  . Évalué à 1. Dernière modification le 23 juin 2022 à 14:40.

            Effectivement tu as un problème d'auth ou de config acl sur bind. Tu peux vérifier que tu utilises la bonne clef, le bon secret et que l'acl est correcte avec nsupdate.

            nsupdate -y KEYNAME:secret

            un fois dans l'invite, tu tappes:

            server un.de.tes.ns
            update add _acme-challenge.subdomain.domain.tld. 600 in txt blabla
            show
            send

            Et tu verras directement si ça marche. Fais bien le test depuis la machine qui fait tourner certbot dans le cas où l'acl vérifier le réseau/addresse source, nsupdate se trouve dans un paquet bind9-tools (au pif).

            Deuxième point, vu que tu as plusieurs NS (dig tondoamin.tld ns), il se peut que tu aie une config master/slave, dans quel cas il faudra t'assurer que tu communiques bien avec le server maître. Je suppose qu'il y a un moyen de force certbot à utiliser un NS au lieu d'auto-détecter la SOA/NS.

            • [^] # Re: regarder comme ca se passe

              Posté par  . Évalué à 1. Dernière modification le 23 juin 2022 à 20:35.

              Voila ce que j'obtiens avec "send"

              ; TSIG error with server: tsig indicates error
update failed: NOTAUTH(BADKEY)

              Pourtant, j'ai bien essayé plusieurs config

              • [^] # Re: regarder comme ca se passe

                Posté par  . Évalué à 3.

                port salut, c'est marqué dessus

                update failed: NOTAUTH(BADKEY)

                la clef envoyé pour autorisé la mise à jour du DNS n'est pas bonne, le serveur rejete alors la mise à jour.

                si c'est un serveur DNS à toi, voit s'il n'a pas aussi une restriction sur les IPs qui sont autorisées à le mettre à jour en plus de la clef

                si le serveur n'est pas à toi (DNS externe chez un grand fournisseur), regarde si certbot à des APIs vers ce fournisseur à qui on donnerait juste un login/pass/APIkey

                • [^] # Re: regarder comme ca se passe

                  Posté par  . Évalué à 1.

                  Il est à moi, mais pour le moment je n'ai pas trouvé la solution !

                  Je peux paste mon fichier de config

                  • [^] # Re: regarder comme ca se passe

                    Posté par  . Évalué à 1.

                    Sans une partie de la config on pourra difficilement t'aider :O. Joins aussi le log de ton bind.

                    Orthogonalement, et au risque de me répéter, tu as 3 serveurs dns, les as-tu tous essayé ? À priori, tu n'en administre qu'un des trois… Ont-ils tous la même clef ? Dans tous les cas, ton certbot devra attendre que l'info soit répliquée sur les 3 avant de continuer le challenge!

                  • [^] # Re: regarder comme ca se passe

                    Posté par  . Évalué à 1.

                    Ok, maintenant le client certbot échange bien avec bind9.

                    Par contre, je dois actuellement mettre une ligne pour l'acme de chaque sous domaine dans bind9 et le update-policy.

                    zone "myne.org" {
   type master;
   file "/etc/bind/zones/db.myne.org";
   forwarders {};
   update-policy {
      grant mykey name _acme-challenge.subdomain.myne.org. txt;
   }

                    Actuellement je devrais avoir une ligne pour chaque subdomain dans l'update-policy !

                    Vous auriez-peut être une syntaxe pour que je n'ai à mettre qu'une ligne pour plusieurs sous-domaines ?

                    • [^] # Re: regarder comme ca se passe

                      Posté par  . Évalué à 1.

                      https://www.zytrax.com/books/dns/ch7/xfer.html#update-policy

                      peut-être grant mykey wildcard _acme-challenge.*.myne.org. txt ?

                      • [^] # Re: regarder comme ca se passe

                        Posté par  . Évalué à 1.

                        '_acme-challenge.*.myne.org.' is not a wildcard

                        • [^] # Re: regarder comme ca se passe

                          Posté par  . Évalué à 4. Dernière modification le 24 juin 2022 à 18:41.

                          peut-etre parce que tu ne peux pas faire un update sur un record qui n'existe pas

                          regarde si tu peux faire un create-policy plutot qu'un update-policy
                          ou si tu peux deja faire un grant mykey all

                          tu verras apres à restreindre ce que peut faire la clef

                          • [^] # Re: regarder comme ca se passe

                            Posté par  . Évalué à 1. Dernière modification le 24 juin 2022 à 18:53.

                            Pour un certificat wildcard, est-ce que cette ligne convient ?

                            certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/auth/rfc2136.ini -d *.domain.fr -d domain.fr ?

                            Ou juste celle-ci ?

                            certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/auth/rfc2136.ini -d *.domain.fr ?

                            • [^] # Re: regarder comme ca se passe

                              Posté par  . Évalué à 1. Dernière modification le 24 juin 2022 à 19:33.

                              Ça dépend si tu as besoin d'avoir un certificat qui couvre ton domaine.tld et nimportequelsub.domain.tld. ou juste nimportequelsub.domain.tld.

                              • [^] # Re: regarder comme ca se passe

                                Posté par  . Évalué à 1.

                                Ok, j'ai un cas particulier.

                                Pour un double subdomain, comment peut-on faire ?

                                Je viens de tester, le certificat wildcard ne me permet pas de valider subdomain.subdomain.mondomain.org

                                Une idée ? Merci

                                • [^] # Re: regarder comme ca se passe

                                  Posté par  . Évalué à 3.

                                  demander un certificat juste pour ce cas là
                                  un certificat x.domain.tld
                                  un certificat y.domain.tld
                                  un certificat a.b.domain.tld

                                  je ne vois pas pourquoi ce serait un souci ?

                                  • [^] # Re: regarder comme ca se passe

                                    Posté par  . Évalué à 1.

                                    Effectivement, mais je pensais qu'on pouvait aller plus loin avec une seule wildcard.

                                    C'est à dire, sous-sous-domaine.

                                    • [^] # Re: regarder comme ca se passe

                                      Posté par  . Évalué à 3.

                                      fait des sous-sous domaine qui n'en sont pas

                                      sub2-sub1.domaine.tld
                                      sub3-sub1.domaine.tld

                                      sinon en vrai ce serait quoi l'interet d'un sous.sous.domaine.tld ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.