Oui, je n’arrivais plus à le retrouver ce F…ameux %F . 
Donc :
echo "# ACTUAL DATE : $(date '+%F %T')"
Par contre, ce n’est pas une très bonne idée de créer une variable dont le nom est aussi le nom d’une commande.
1 J'aime
@MicP @Sputnik93 oui merci… man ; info date 
C’était pour avoir une variable « static » de la date pour si le script s’exécuterait en 1, 10min que les dates ne change pas et pour récupérer les valeurs en début de script et les avoir tout au long du script (dans le script « dnssec-sign-zones.bash »)
Et en plus, bon, ok, dans ce script « dnssec-sign-myzones.bash » oui c’est vrai j’aurais dû faire çà ok messieurs 
oui c’est vrai
PS : vous avez remarqués, bon élève que je suis, j’ai mis mes variables en minuscule et je nomme mes scripts BASH (Bourne-Again shell) en « .bash » maintenant 
Oui ok - Et mon exit 150 dans le script « dnssec-sign-zones.bash » c’est moche non ? C’était çà la question
Bonne journée
Salutations,
Romain
Tu pourrais peut-être, au début de ton script dnssec-sign-zones.bash
mettre la ligne de commande suivante :
set -e
ce qui fait que tu n’aurais pas besoin de tester si une des lignes de commandes contenue dans ton script ne fonctionne pas, ni à positionner un code d’erreur résultant pour l’afficher en quittant le script.
Voir la page man de bash concernée
en entrant la ligne de commande suivante :
man --pager='less -p "-e Se"' bash
Merci beaucoup @MicP ! Je regarde çà
Ton man est en « FR » ou « EN » ? « Pattern not found » Je recherche des docs…
Bonne journée merci.
En fait ce n’est pas un retour d’erreur mais plutôt un retour « perso » pour que je sache qu’une ou plusieurs zones on étaient modifiées et donc qu’il faut que je restart le serveur.
Oui, il est en français, mais le formatage de sortie de pages man insère plus ou moins de caractères espaces entre les mots en fonction de la taille de la fenêtre du terminal utilisé.
Voici l’extrait de la page man concerné par l’option e
Avec cette option, ce sera ta commande qui, en cas d’échec, arrêtera là le déroulement du script en transmettant son code de sortie au script, et donc, le code de sortie retourné par ton script sera beaucoup plus pertinent.
Fais un test avec l’option e pour voir si ça convient à ce que tu veux faire.
1 J'aime
Merci beaucoup
oui j’essairais. Merci encore @MicP
En fait dans mon script « dnssec-sign-zones.bash » par exemple si je --force en exécutant manuellement la commande pour signer la zone je souhaite redémarrer le serveur.
Et si j’utilise le script « dnssec-sign-zones.bash » plusieurs fois depuis l’autre script « dnssec-sign-myzones.bash » qui fait une boucle sur plusieurs zones - je souhaite avoir une sortie pour savoir si je dois redémarrer ou non le serveur DNS.
# ici on est déjà dans la "if" du -> on re-sign de la zone <-> on l'a déjà re-signée
if [ ${force} -eq 1 ]; then
/etc/init.d/bind9 restart
echo " +-> Bind server DNS reload"
exit 0
else
exit 150
fi
Et dans l’autre script :
status=()
restart_server_dns=0
domains_list="domain_1.tld domain_2.tld"
for domain in ${domains_list}
do
/root/dnssec-sign-zones.bash -d ${domain} -f /etc/bind/masters/${domain}.hosts
status+=( "$(printf "%d\n" $?)" )
done
Et là je reboucle et si je trouve un 150 en sortie je redémare le serveur.
for code in "${status[@]}"; do
#echo "Code : ${code}"
if [ ${code} -eq 150 ]; then
restart_server_dns=1
fi
done
if [ ${restart_server_dns} -eq 1 ]; then
/etc/init.d/bind9 restart
echo "+-> Bind server DNS reloading|restarting"
fi
Simple
On peut faire mieux c’est sûr 
Bon, que la journée soit bonne et productive.
Romain
Peut-être, mais même avant que je t’apporte un peu d’aide, c’est déjà nettement mieux que ce que j’avais pu faire dans mes premiers scripts.
Et puis il y a tellement longtemps (environ 7 ans) que je n’ai pas eu besoin d’utiliser la commande bind que je serai bien en peine de pouvoir t’aider dans ce domaine car je me doute qu’il doit y avoir beaucoup de choses qui ont évolué.
J’ai changé un -eq en -le ^^^ çà buggué mon script → avant la déclaration du resign=1 
Ligne je n’sais plus combien
Bonjour,
Bon, en passant
Mon script commentaire 8 pour mettre à jour périodiquement mes zones DNSSEC ne sert à rien !
Les zones se mettent à jour seules. Alors, je ne sais pas encore comment, mais j’ai remarqué çà grâce à zw3b.blog | DNSViz.
Çà me créent des journaux de mise à jours dynamique (des fichiers « .jnl ») que l’on peut lire de cette manière :
root@lv1.dns:~ # named-journalprint /etc/bind/masters/zw3b.blog.hosts.signed.jnl
del zw3b.blog. 3600 IN SOA dns.lab3w.fr. hostmaster.lab3w.fr. 2022101707 300 60 420 60
del w1w.zw3b.blog. 3600 IN RRSIG AAAA 8 3 3600 20221116142413 20221017142413 13710 zw3b.blog. p6yU9/8et+/Jzg/iDP........fq6Uiil72mVpTsp0OUzu9 8Dw=
del o-romain-jaillet-ramey.zw3b.blog. 3600 IN RRSIG CNAME 8 3 3600 20221116142413 20221017142413 13710 zw3b.blog. nidERqWbmdtEpDQEd0........1XydvymmAbkbJ 4Pk=
del *.zw3b.blog. 60 IN RRSIG NSEC 8 2 60 20221116142413 20221017142413 13710 zw3b.blog. pif+pkemCqmLg34h6zYx........7KvsxJEzk0ZK5VnhRQ+Zw/Ex sXg=
del dl.zw3b.blog. 60 IN RRSIG NSEC 8 3 60 20221116142413 20221017142413 13710 zw3b.blog. GTO7D4uFRI6+x7hh/J........Nj+G1JECUXhyQWhDjggi7JOUU2jh h1k=
del dl.zw3b.blog. 3600 IN RRSIG CNAME 8 3 3600 20221116142413 20221017142413 13710 zw3b.blog. NTSsxTA........VPzXIr+C hpE=
del ksso0s.zw3b.blog. 3600 IN RRSIG CNAME 8 3 3600 20221116142413 20221017142413 13710 zw3b.blog. UXziiCfzHkdX........ASrlJSJ496HWNCeOe9/sCN2TjCuOU1tpphR9wHnXTCB2X +Ck=
del lab3w.zw3b.blog. 3600 IN RRSIG CNAME 8 3 3600 20221116142413 20221017142413 13710 zw3b.blog. lD+nzBHapGI........+pirrYh8jRw7C/vssWsnIWe4imBYM/7byev4Xop5Bay Xi0=
del _dmarc.w1a.zw3b.blog. 60 IN RRSIG NSEC 8 4 60 20221116142413 20221017142413 13710 zw3b.blog. IVtK13cES62dsad/Sk........af2RCpRwDuyiDtV+kP3 j5M=
del ksso0s.zw3b.blog. 60 IN RRSIG NSEC 8 3 60 20221116142413 20221017142413 13710 zw3b.blog. H7bSlIVZL7Br7HTZUyjHHW8It........ ws3dJ/Sr56Ssw2Jz8bViyde6oYTjJbxLjschMr6hSiQx/zbpyjvzQc6l WQk=
del _dmarc.w1a.zw3b.blog. 10800 IN RRSIG TXT 8 4 10800 20221116142413 20221017142413 13710 zw3b.blog. GyP6OEQTGEyBIpG/........8qF36+/ ikCXoJOvIIOlpmtFM0HBc9NVPQUVe/nzJD6UElz664MDH3RfvS86784w HJI=
del lab3w.zw3b.blog. 60 IN RRSIG NSEC 8 3 60 20221116142413 20221017142413 13710 zw3b.blog. JtwbLMeUnfc++9GFntleNSW2jiBrFmE........zJSiEW0R+EgTOBP6YFSU6EXOlLTX0yUw8BkbL Ow8=
del zw3b.blog. 3600 IN RRSIG SOA 8 2 3600 20221209022414 20221109012414 13710 zw3b.blog. VGBbTp2pl+YMB52ls5NpLctr2MV7........+UKTO9XPADTcjozOU7jxiT7wJ G2A=
.....
add zw3b.blog. 3600 IN SOA dns.lab3w.fr. hostmaster.lab3w.fr. 2022101708 300 60 420 60
add w1w.zw3b.blog. 3600 IN RRSIG AAAA 8 3 3600 20221209015804 20221109012414 13710 zw3b.blog. OQ+OgLNhWvsHg7s1MFZ........Wiiw4jXElmUpX5SY7Gll0qIF XNU=
add o-romain-jaillet-ramey.zw3b.blog. 3600 IN RRSIG CNAME 8 3 3600 20221209015804 20221109012414 13710 zw3b.blog. H6dOOebCrEtBoq........GVW5MoXW6skti28g6F ep8=
add *.zw3b.blog. 60 IN RRSIG NSEC 8 2 60 20221209015804 20221109012414 13710 zw3b.blog. KprpU5DhZn9vV19........EzfAQO18ZwgyM4OP18DbkeQ3eHyTqOr/2M 1No=
add dl.zw3b.blog. 60 IN RRSIG NSEC 8 3 60 20221209015804 20221109012414 13710 zw3b.blog. WpyyiEw6AAGV........IYFkV1xUDCy Yys=
add dl.zw3b.blog. 3600 IN RRSIG CNAME 8 3 3600 20221209015804 20221109012414 13710 zw3b.blog. K9317AJat9UGG........KITo6NqqEEoDQ58Pl Iu4=
add ksso0s.zw3b.blog. 3600 IN RRSIG CNAME 8 3 3600 20221209015804 20221109012414 13710 zw3b.blog. WqU/6k7goFERbrpf........gmOHngZOExep0sp3P4lHw +Tk=
add lab3w.zw3b.blog. 3600 IN RRSIG CNAME 8 3 3600 20221209015804 20221109012414 13710 zw3b.blog. ZZN/WVgS13........0+Y4w3qqXUyiBPAJ xXY=
add _dmarc.w1a.zw3b.blog. 60 IN RRSIG NSEC 8 4 60 20221209015804 20221109012414 13710 zw3b.blog. SUtLerSthFOU7........xmGGwUYLyo0YFFugGb3blQ 6xA=
add ksso0s.zw3b.blog. 60 IN RRSIG NSEC 8 3 60 20221209015804 20221109012414 13710 zw3b.blog. j8lFOrApsZ8nE........786I3 hJw=
add _dmarc.w1a.zw3b.blog. 10800 IN RRSIG TXT 8 4 10800 20221209015804 20221109012414 13710 zw3b.blog. nxnr9zq1O........vV+WZllgfa n3E=
add lab3w.zw3b.blog. 60 IN RRSIG NSEC 8 3 60 20221209015804 20221109012414 13710 zw3b.blog. JH/wCkT23/vG2f0uBSbiuIiZ33........o2ztG P6Y=
La valeur de l’inception et de l’expiration sont donc récupérer depuis les valeurs de NSEC(3)PARAM
NSEC : NextSECure
Il faut que j’essaie çà !
Bonne journée.
Salutations,
Romain
Bonjour,
J’ai enfin installé Let’s Encrypt, « une » autorité de certification gratuite, automatisée et ouverte proposée par l’Internet Security Research Group (ISRG) à but non lucratif.
Le Plugin FireFox « DNSSEC/DANE Validator (Validate DNSSEC & DANE using DoH) » fonctionne très bien, j’ai ma clé verte : l’hôte est sécurisé DNSSEC et DANE valide.
Je me disais que je vais devoir créer un script pour mettre à jour les RR (Ressource Records) TLSA par nsupdate juste après les MàJ (Mises à Jour) des certificats.
Il « pourrait » y avoir un getops à certbot et/ou acmesh pour mettre à jour les valeurs TLSA des nouveaux certificats.
Bonne journée.
Note de Moi-même : J’ai trouvé un autre plugin FireFox de visualisation DNSSEC d’ Antoine POPINEAU, un bon (bonne personne ) français vu son nom de famille Essayez, si, cela vous plaît.
Bonjour,
Pour DANE (DNS based Authentication of Named Entities) et la ressource record TLSA ( Transport Layer Security Authentication), comment puis-je récupérer la date d’expiration des certificats de Let’s Encrypt sans interroger le certificat local ?
Je pense à DoHjs, mais je ne vois pas comment « injecter » une demande sans API (cliente) autorisée (moi, un de mes serveurs) - ll faut activé de l’option avancée, « envoyer le DNSSEC OK (bit DO) ».
En envoyant depuis le formulaire DoHjs qui me retourne bien un « JSON object data » avec :
"questions": [
{
"name": "_443._tcp.zw3b.eu",
"type": "TLSA",
"class": "IN"
}
],
"answers": [
{
"name": "_443._tcp.zw3b.eu",
"type": "TLSA",
"ttl": 3600,
"class": "IN",
"flush": false,
},
{
"name": "_443._tcp.zw3b.eu",
"type": "RRSIG",
"ttl": 3600,
"class": "IN",
"flush": false,
"data": {
"typeCovered": "TLSA",
"algorithm": 8,
"labels": 4,
"originalTTL": 3600,
"expiration": 1672840023,
"inception": 1670244423,
"keyTag": 45480,
"signersName": "zw3b.eu",
"signature": "Di...fw"
}
}
],
.....
Je vois bien un timestamp « inception » et « expiration » mais comment puis-je récupérer cette valeur depuis un script ?
Qui correspond à l’inception et l’expiration du certificat SSL → cooL → DoHjs y arrive (CF résultat du dessus).
16:55:50 root@dc.w3a:~ $ echo 'TLSA Date Inception' : $(date '+%F %T' -d '@1670244423')
TLSA Date Inception : 2022-12-05 13:47:03
16:55:57 root@dc.w3a:~ $ echo 'TLSA Date Expiration' : $(date '+%F %T' -d '@1672840023')
TLSA Date Expiration : 2023-01-04 14:47:03
Qui a/aurait une autre solution (Full Linux) pour que je puisse mettre à jour mes RR TLSA à la mise à jour des certificats SSL/TLS que Let’s Encrypt me re-génére tous les 3 mois par NSUPDATE histoire d’être toujours valide DANE ?
Bon, je vais installer la librairie JS GitHub DoHjs quelque part - exemple HTML, BIN
Par OpenSSL est-ce possible - ou - sur une base publique de Let’s Encrypt ?
Merci.
J’ajoute l’imprime écran du certificat :
Validité :
Pas avant : Thu, 01 Dec 2022 14:33:48 GMT
Pas après : Wed, 01 Mar 2023 14:33:47 GMT
Ce ne sont pas les même minutes/secondes
Salutations.
Romain
J’ajoute ces 2 lignes qui récupérent la date d’inception et d’expiration du Ressource Record NSEC3 qui se re-génére tous les mois.
17:22:18 root@lv1.dns:~ # nsec3_param_date_inception=$(dig RRSIG zw3b.eu | grep NSEC3PARAM | awk '{print $10}'); echo NSEC3 Inception Date : ${nsec3_param_date_inception:0:4}-${nsec3_param_date_inception:4:2}-${nsec3_param_date_inception:6:2} ${nsec3_param_date_inception:8:2}h${nsec3_param_date_inception:10:2}m${nsec3_param_date_inception:12:2}s
NSEC3 Inception Date : 2022-12-01 15h58m13s
17:23:52 root@lv1.dns:~ # nsec3_param_date_expiration=$(dig RRSIG zw3b.eu | grep NSEC3PARAM | awk '{print $09}'); echo NSEC3 Expiration Date : ${nsec3_param_date_expiration:0:4}-${nsec3_param_date_expiration:4:2}-${nsec3_param_date_expiration:6:2} ${nsec3_param_date_expiration:8:2}h${nsec3_param_date_expiration:10:2}m${nsec3_param_date_expiration:12:2}s
NSEC3 Expiration Date : 2022-12-31 15h58m13s
Ce genre de script peux aider à s’organiser.
2 J'aime
Super génial, merci beaucoup (encore) @Clochette !
SSL Certification Expiration Checker
root@lv1.w1a:~/ssl-cert-check # ./ssl-cert-check -f ssldomains
Host Status Expires Days
------------------------------------------- ------------ ------------ ----
www.lab3w.fr:443 Valid Feb 25, 2023 81
www.lab3w.com:443 Valid Feb 25, 2023 81
swan.lab3w.com:443 Valid Feb 25, 2023 81
admin.lab3w.com:443 Valid Feb 25, 2023 81
www.zw3b.fr:443 Valid Feb 25, 2023 81
howto.zw3b.fr:443 Valid Feb 25, 2023 81
radio.zw3b.fr:443 Valid Feb 25, 2023 81
www.zw3b.tv:443 Valid Feb 25, 2023 81
www.zw3b.net:443 Valid Feb 25, 2023 81
www.zw3b.site:443 Valid Feb 25, 2023 81
kss.zw3b.site:443 Valid Feb 25, 2023 81
lab3w.zw3b.site:443 Valid Feb 25, 2023 81
www.zw3b.blog:443 Valid Feb 25, 2023 81
www.zw3b.eu:443 Valid Mar 1, 2023 85
www.ipv01.net:443 Valid Feb 25, 2023 81
www.ipv10.net:443 Valid Feb 25, 2023 81
Documentation And Examples: http://prefetch.net/articles/checkcertificate.html
Bon j’essaie de sortir çà en JSON avec la « commande » jc - çà ne marche pas 
:
root@lv1.w1a:~/ssl-cert-check # jc -r -p /root/ssl-cert-check -i -f ssldomains
jc: Error - "/root/ssl-cert-check -i -f ssldomains" cannot be used with Magic syntax. Use "jc -h" for help.
Et si, ssl-cert-check me sortait un timestamp ce serait génial - Y’a le nombre de jour restant, çà c’est cooL
Bonne soirée à vous mesdames, messieurs.
Romain
Bonjour, bonsoir.
J’ai réussis à récupérer la valeur que je souhaitais réponse « inception/expiration » d’un RR TLSA (commentaire 32) :
root@lv1.w1a:~ # timestamp_tlsa=$(node -pe 'JSON.parse(process.argv[1]).answers[1].data.expiration' "$(dohjs https://dns.google/dns-query _443._tcp.zw3b.eu TLSA -m GET +dnssec)"); echo 'TLSA Date Expiration' : $(date '+%F %T' -d "@${timestamp_tlsa}")
TLSA Date Expiration : 2023-01-04 14:47:03
ou de cette manière 
(je m’étais embrouiller à parser le JSON) avec la « commande » jq :
root@lv1.w1a:~ # dohjs https://dns.google/dns-query _443._tcp.zw3b.eu TLSA -m GET +dnssec | jq -r .answers[1].data.expiration
1672840023
root@lv1.w1a:~ # timestamp_tlsa=$(dohjs https://dns.google/dns-query _443._tcp.zw3b.eu TLSA -m GET +dnssec | jq -r .answers[1].data.expiration) ; echo 'TLSA Date Expiration :' $(date '+%F %T' -d "@${timestamp_tlsa}")
TLSA Date Expiration : 2023-01-04 14:47:03
Note de Moi-même : C’est la 1ère fois que j’installe l’API Node.js
Détails : installer nodejs et le Node.js Package Manager (npm) :
# apt install nodejs npm
# nodejs -v
v10.24.0
# npm -v
5.8.0
Installer à nodejs des modules (ex : dohjs) ET cela dans le répertoire global ("-g") par npm.
# npm install npm@latest -g
# npm install https@latest -g
# npm install dns-packet@latest -g
# npm install dohjs -g
Avec l’option « -g », les modules s’installent ici.
# ls -l /usr/local/lib/node_modules/
total 16
drwxr-xr-x 3 root root 4096 déc. 7 01:35 dns-packet
drwxr-xr-x 8 root root 4096 déc. 7 01:36 dohjs
drwxr-xr-x 2 root root 4096 déc. 7 01:35 https
drwxr-xr-x 7 root root 4096 déc. 7 01:29 npm
Ensuite je peut donc utiliser DoH :
# dohjs -v
0.2.0
# dohjs https://dns.google/dns-query _443._tcp.zw3b.eu TLSA -m GET +dnssec
Par exemple « parser » avec du javascript (nodejs) qui me permet de récupérer le timestamp de la date d’expiration du champ TLSA.
# node -pe 'JSON.parse(process.argv[1]).answers[1].data.expiration' "$(dohjs https://dns.google/dns-query _443._tcp.zw3b.eu TLSA -m GET +dnssec)");
1672840023
Et puis j’ai ajouté la commande date pour avoir la date et les heures/minutes/secondes.
# timestamp_tlsa=$(node -pe 'JSON.parse(process.argv[1]).answers[1].data.expiration' "$(dohjs https://dns.google/dns-query _443._tcp.zw3b.eu TLSA -m GET +dnssec)")
# date '+%F %T' -d "@${timestamp_tlsa}"
2023-01-04 14:47:03
C’est déjà bien…
Post Scriptum :
Il y a une différence entre la date d’expiration du certificat « Wed, 01 Mar 2023 14:33:47 GMT » et celle de la valeur de l’expiration du champ TLSA qui est avant (c’est peut-être DNSSEC - pourtant non).
SSL/TLS Inception Date
2022-12-01 14:33:48
SSL/TLS Expiration Date :
2023-03-01 14:33:47
DANE TLSA Inception Date
2022-12-05 13:47:03
DANE TLSA Expiration Date :
2023-01-04 14:47:03
DNSSEC NSEC3 Inception Date (rien à voir avec les certificats SSL OK)
2022-12-01 15:58:13
DNSSEC NSEC3 Expiration Date :
2022-12-31 15:58:13
Qué bordel 
Note de Moi-même : ¿il faut donc mettre à jour le RR TLSA tous les mois? - À vérifier.
Pourtant DANE est lié au certificat justement - Il ne va pas y avoir une autre valeur à la commande ci-dessous puisque c’est toujours le même certificat SSL/TLS.
# openssl x509 -noout -fingerprint -sha256 < /var/local/letsencrypt/data/zw3b.eu_ecc/zw3b.eu.cer | tr -d :
SHA256 Fingerprint=BF5D0425AD332E366432542C83A8827A498E737BB53F59D70AAA940BBA2C24A6
j’ajoute les commandes openssl pour lire le certificat d’un service :
# echo | openssl s_client -servername www.zw3b.eu -connect zw3b.eu:443 | openssl x509 -noout -dates -checkend '86400'
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = zw3b.eu
verify return:1
notBefore=Dec 1 14:33:48 2022 GMT
notAfter=Mar 1 14:33:47 2023 GMT
Certificate will not expire
-checkend '86400' (1 jour) → Certificate will not expire
-checkend '7344000' (85 jours) → Certificate will expire
Bon j’ai fais çà pour les certificats SSL :
# expiryDays=$(( ($(date -d "$(echo | openssl s_client -servername www.zw3b.eu -connect zw3b.eu:443 -verify_quiet | openssl x509 -enddate -noout | awk -F= '{print $2}')" '+%s') - $(date '+%s')) / 86400 )) ; echo ${expiryDays}
84
# expiryDays=$(echo $(echo $(date -d "$(echo | openssl s_client -servername www.zw3b.eu -connect zw3b.eu:443 -verify_quiet | openssl x509 -enddate -noout | awk -F= '{print $2}')" '+%s') - $(date '+%s') | bc -l) / 86400 | bc -l) ; echo ${expiryDays}
84.34645833333333333333
# expiryHours=$(( ($(date -d "$(echo | openssl s_client -servername www.zw3b.eu -connect zw3b.eu:443 -verify_quiet | openssl x509 -enddate -noout | awk -F= '{print $2}')" '+%s') - $(date '+%s')) / 3600)) ; echo ${expiryHours}
2024
Romain
Hello.
La différence entre les dates du cert et celle du|des TLSA sont normales. Ce sont deux choses différentes, totalement…
TLSA étant un enregistrement DNS en rapport avec tout ce qui est TLS sur TCP|UDP, voire SCTP.
Ils dépendent de ton cert mais n’ont directement rien à voir avec les dates du cert.
Tu t’enquiquines sérieusement la vie.
Récupères la date d’expiration de ton cert, pour pouvoir en générer un nouveau si besoin.
Suite à la (ré)génération du cert, génère un enregistrement TLSA lié au couple port/protocole que tu souhaites valider pour tes clients.
Les enregistrements TLSA ne sont pas à régénérer tous les mois, mais à chaque régénération du cert TLS. Car dès le changement suite à renouvellement d’un cert, les enregistrements TLSA ne sont plus valide et donc un client capable de les lire ne pourra plus accéder au service concerné.
Si dans les faits, tu peux générer des enregistrements TLSA pour :
- 443 TCP
- 853 TCP et UDP
- 587 TCP
- etc…
Il faut bien comprendre que le client doit être capable
- d’interroger un serveur DNS pour récupérer l’enregistrement TLSA correspondant au protocol qu’il va requêter.
- d’analyser l’enregistrement TLSA
- de traiter correctement l’enregistrement TLSA
- et d’en tenir compte lors de sa requête vers le service en question.
Si pour nous cela a du sens, ce n’est pas forcément le cas pour un client IT… - si je ne me trompe pas … -, aucun client MUA n’est actuellement capable de gérer un enregistrement TLSA, donc, le client va quand même chercher à se connecter, sans savoir s’il y a un potentiel problème de datation de cert ou pas. Si le service répond « convenablement » au port/protocole, le client obtiendra les informations pertinentes.
Ceci n’est pas le cas de client « web ». La plupart des actuels interrogeront le serveur DNS, récupéreront l’enregistrement TLSA correspondant, et s’il y a correspondance et donc validité avec celui du service, la connexion sera faite.
(dsl, si mon propos n’est pas totalement clair ; suis sous Codèine, car Covid en + de ma MIC… sans parler d’erreur d’interprétation de ma part)
1 J'aime
Merci @PengouinPdt tes propos sont trés clair.
J’espère que tu vas rester avec noUs, j’en suis sûr. Portes toi bien.
OK, merci je regardes SCTP.
Ok, j’ai pensé le contraire.
C’est à cause du champ « answers → expiration » du retour par DoHjs 
. Je me disais que cela devais correspondre avec les dates du certif SSL.
Ouais, j’ai configuré Acme.sh en --dns_nsupdate, je pense qu’il va re-générer mes certificats Let’s Encrypt, automatiquement, non ?
Ouais, j’en étais là, il faut que je teste les options --post-hook de AcmeSH et faire un script via nsupdate pour ces RR et envoyer les nouveaux certif sur les containers et machines virtuelles, des frontaux 
Il faut « reload » aussi le(s) serveurs web, j’avais oublié (sinon je pense (peut-être mal) que les certificats ne vont pas être rechargés et considérés comme expirés même si ils portent le même nom.
Note de Moi-même : J’ai mis une alarme sur mon calendrier le jour de l’expiration de certifs 
Oui, çà au départ, j’avais compris, compris comme çà
Oui - DANE n’est pas encore beaucoup implanter sur les clients.
oUais
Je me demande si, en SEO (référencement) ça peut valoir des points supplémentaires comme « le fait » d’avoir des liens https, et d’être en https. Çà m’étonnerait 
Merci en tout cas @PengouinPdt pour ces « précisions » d’informations trés précieuses.
Romain.
AUCUN !
Tu ne fais qu’améliorer la sécurité/validité des informations que tu transmets !
Depuis les enregistrements DNS, jusqu’à la connexion TLS, par TCP/UDP…
tu valides tel service que tu rends dispo, sur tel protocole, sur tel port, a telle signature DNSSEC.
En fait, tu agis comme si tu étais une AC pour ta zone DNS, grâce au protocole DNSSEC, et à ses enregistrements TLSA. (c’est exactement le même principe)
Si l’information est valide, alors on peut lui attribuer de la confiance, donc on peut se connecter au service relatif… ça ne valide pas l’information fournie par le service en question ; ça ne valide que les informations DNS pour s’y connecter.
C’est le principe de confiance par l’autorité.
De ? 
Aucune chance… Qui sait, si les seigneurs du référencement y pensent, peut-être
Oui justement, si le client « Google Bot » pouvait savoir/vérifier/noter si, en plus d’être en HTTPS (+10), si le (mon) nom domaine d’un site web est valide DNSSEC (+1000 points), et, si, en plus, l’entité (vhost) du domaine est valide DANE (+2000 points), qu’ils (Google Bot) se disent que c’est en site de confiance plus qu’un autre.
Je peut expliquer, autrement ; je peut avoir un certificat SSL en mode « wildcard » sur un domaine qui validerait tous mes vhosts (sans DANE) et avoir un autre certificat SSL pour le vhost « www (dot) domain (dot) tld » et « domain (dot) tld » avec DANE qui certifierait que je suis « maître » du nom de domaine (sans certifier tous les autres sites en sous-domaine). Ou pour un autre protocole (style) smtp, pop, imap, ldap qui « prouverait » que ces services « en particulier » sont gérés par l’entité propriétaire (moi).
Oui, j’ai cru lire que cela permet d’interroger le DNS (plus rapide) à la place de toute la chaine de confiance de l’AC (Autorité de certification).
Oui donc je pensais référencement (SEO).
J’essaie de ne pas mettre d’informations erronées sur mes sites Web 
Ouais
Merci @PengouinPdt