Plop, pour les détails :

[ven. juin 15 16:02:15 CEST 2018] Please add '--debug' or '--log' to check more details.

Bonjour à tous

J'utilise le serveur DNS autoritaire avec NSD/DNSSEC via Docker de Hardware, et dans le fichier de zone figure mes enregistrement DANE/TLSA.

Mes certificats arrivant à expiration je me pose les questions suivantes. Bien que mon registrar soit Gandi, mon fichier zone est en local sur mon serveur, du coup, me semble t-il je ne peux pas utiliser l'api Gandi pour l'insertion de l'enregistrement TXT, enfin je crois

Dans ces conditions est ce que l'implantation du wildcard en renouvellement est possible ? Par ailleurs et j'en profite pour vous demander si avez vous un script pour renouveler les enregistrement TLSA lorsque les certificats letsencrypt sont renouvelés et enfin @Hardware parle dans son github de mettre en place un cron pour incrémenter le numéro de série du fichier de zone et pour la signature DNSSEC qui doit être effectuées tous les mois. Quelle commande cron pourrait être adaptée ?

https://github.com/hardware/nsd-dnssec

Merci

laster13 Pour le script je dois avoir ça sous la main mais c'est dans un de mes anciens backups...

Après c'est pas compliqué à faire .
Pour ce qui est d'incrémenter le numéro de série c'est à coups de sed et compagnie une fois que t'as extrait le numéro de la zone. Ensuite tu script pour faire en sorte de récupérer l'empreinte du certificat et tu remplaces l'ancien enregistrement (moi je me cassais pas la tête je récupérais l'empreinte de l'ancien certificat puis je faisais un bon vieux sed). En tous cas je l'avais bricolé comme ça et ça fonctionnait, maintenant que j'utilise traefik qui gère aussi mes certificats je dois un peu modifier mon truc.

L'entrée cron était sur l'hôte, de toute façon la seule commande Docker à faire était le signzone à la fin. Je pourrais songer à PR (ou laisser faire Hardware) pour que ce soit intégré mais en tout cas c'est faisable comme cela.

Wonderfall Merci je vais creuser la commande sed.

Hardware Je te tiens au courant, par contre je vois que tu utilises du SAN plutôt que du Wildcard. Une raison particulière pour ce choix ?

Je m'étais pas penché sur la méthode de renouvellement d'un certificat wildcard avec mon conteneur NSD, donc c'est pour ça que je suis resté sur un SAN. Ensuite j'ai vu ton tuto ^^

Pour le moment, je laisse comme ça, j'ai pas vraiment d'utilité à mettre un wildcard sur mondedie.fr.

Pas mal le script.
Moi j'utilisais ça, mais pas avec acme.sh :

f_check_certs() {
    cd /etc/letsencrypt/live

    for domain in `find * -type d`; do
        FULLCHAINFILE=/etc/letsencrypt/live/${domain}/fullchain.pem
        openssl x509 -checkend 864000 -noout -in "${FULLCHAINFILE}" &>/dev/null

        if [ $? == 0 ]; then
            f_log INF "Certificate for ${domain} is good for another 10 days!"
        else
            f_log INF "Time to renew ${domain}!"

            f_log INF "Downloading cerbot image..."
            docker pull certbot/certbot &>/dev/null

            f_log INF "Stopping nginx..."
            service nginx stop &>/dev/null

            f_log INF "Renewing ${domain}..."
            old_fingerprint=$(openssl x509 -noout -in "${FULLCHAINFILE}" -fingerprint -sha256 | cut -c 20- | sed s/://g | awk '{print tolower($0)}')

            cd ${domain}
            cp cert.pem old_cert.pem && cp chain.pem old_chain.pem && cp fullchain.pem old_fullchain.pem

            docker run -ti --rm -p 80:80 -p 443:443 -v /etc/letsencrypt:/etc/letsencrypt certbot/certbot \
                certonly --standalone --agree-tos -m wonderfall@targaryen.house \
                --csr /etc/letsencrypt/live/${domain}/csr.der \
                --cert-path /etc/letsencrypt/live/${domain}/cert.pem \
                --chain-path /etc/letsencrypt/live/${domain}/chain.pem \
                --fullchain-path /etc/letsencrypt/live/${domain}/fullchain.pem

            new_fingerprint=$(openssl x509 -noout -in "${FULLCHAINFILE}" -fingerprint -sha256 | cut -c 20- | sed s/://g | awk '{print tolower($0)}')

            f_log INF "Certificate renewed for ${domain}."

            f_log INF "Starting nginx..."
            service nginx start &>/dev/null

            f_log INF "Updating TLSA records..."
            sed -i "s/${old_fingerprint}/${new_fingerprint}/g" /home/docker/nsd/zones/db.${domain}
            dns_update.sh ${domain}

            f_log INF "Done!"
        fi
    done
}

domain=$1
f_log INF "Domain set to ${domain}."
old_serial=$(grep "Serial" /home/docker/nsd/zones/db.${domain} | grep -o '[0-9]\+')
new_serial=${old_serial} && let new_serial++
sed -i -e "s/${old_serial}/${new_serial}/g" /home/docker/nsd/zones/db.${domain}
f_log INF "Incremented serial."
f_log INF "Signing DNS zone..."
docker exec nsd signzone ${domain} &>/dev/null
f_log INF "Done."

C'est moins propre mais ça faisait le boulot. Si tu fais ton truc pars plutôt ce qu'a fait Hardware je pense. Perso faut je revois ça pour traefik et comment dump les certs de acme.json d'abord...

Au passage, je ne suis pas fan du wildcard, pourquoi ? C'est bien si l'utilises sur un seul serveur, mais sinon c'est une mauvaise pratique que d'éparpiller des clés privées à d'autres serveurs dont la compromission de l'un peut mener à la compromission de l'ensemble du domaine. Tous les sous-domaines sont à risque quand tu fais un wildcard (SPOF). Je ne dis pas qu'il faut éviter, je dis juste qu'il faut être prudent...

Wonderfall Au passage, je ne suis pas fan du wildcard, pourquoi ? C'est bien si l'utilises sur un seul serveur, mais sinon c'est une mauvaise pratique que d'éparpiller des clés privées à d'autres serveurs dont la compromission de l'un peut mener à la compromission de l'ensemble du domaine. Tous les sous-domaines sont à risque quand tu fais un wildcard (SPOF). Je ne dis pas qu'il faut éviter, je dis juste qu'il faut être prudent...

Je ploussoie la remarque sur le wildcard.

Je viens de tester tes scripts pour le renouvellement des enregistrements TLSA et ca fonctionne nickel. C'est plus léger que le script que j'ai proposé dans le tuto, l'auteur inscrit dans la zone l'ancien TLSA en "old-dane-hash" que son script supprime après 24 heures. Il considère que ce délai est nécessaire pour la propagation des enregistrements.

L'idée est qu'il n'y ait pas de "trou" dans le relais des 2 enregistrements TLSA, d’où ma question, est que le nouvel enregistrement est pris en compte immédiatement au niveau DNS ?

Edit : c'est peu etre un bug mais du coup le plugin HTTPS+ Checker de firefox montre que dnssec et dane ne sont pas actif sur mondedie.

A priori la valeur de la variable "$expiration_date" est trop grande, un warning sur zonemaster

DNSSEC 	WARNING 	La signature (RRSIG) avec la clé de tag 27616 et couvrant les enregistrements de type(s) "DNSKEY" a une durée de validitée restante de 15770474 secondes, ce qui est trop long. 

A la question de savoir si les enregistrement TLSA étaient pris en compte immédiatement, le site https://www.huque.com/bin/danecheck me confirme que oui.

Du coup, le renew des certificats génére une signature DNSSEC pour 6 mois ce qui fait qu'on a plus besoin de se préoccuper de la signature de zone. Par ailleurs je ne connaissais pas ce système de notifications slack intégrable dans les scripts, je trouve ça génial, je vais mettre à jour tous mes scripts.

J'ai testé ton script pour le wildcard en rajoutant les options suivantes :

certbot certonly --rsa-key-size 4096 --manual --preferred-challenges=dns --manual-auth-hook /mnt/docker/nsd/leadd.sh --manual-cleanup-hook /mnt/docker/nsd/ledel.sh --renew-hook "service nginx reload" --post-hook "update-mail-tlsa" ...

Cela fonctionne très bien et avec au final les paramètres renew

# Options used in the renewal process
[renewalparams]
installer = None
manual_cleanup_hook = /mnt/docker/nsd/ledel.sh
authenticator = manual
manual_public_ip_logging_ok = True
pref_challs = dns-01,
account = fd7a3565aba701........
server = https://acme-v02.api.letsencrypt.org/directory
manual_auth_hook = /mnt/docker/nsd/leadd.sh
rsa_key_size = 4096
post_hook = update-mail-tlsa
renew_hook = service nginx reload

Au final ton script est vraiment super et je souhaiterais adapter mon tuto avec si tu es d'accord de manière à pouvoir le garder disponible avant qu'il se noie parmi les autres posts. Si tu es ok pour déverrouiller le tuto

Reste plus qu'à trouver un moyen de renouveler automatiquement les clés ZSK et KSK mais surtout de pouvoir incrémenter le fingerprint auprès de Gandi sans avoir a le faire manuellement .. peut être avec l'Api livedns de gandi, je vais creuser ..

Plutôt que de rentrer le fingerprint dans gandi, ne peut on pas tout simplement mettre un enregistrement (je sais pas quoi) dans le fichier de zone qui ferait le boulot ?