C'est encore en travaux, et en plus, j'ai à peine le temps de bosser dessus. Mais c'est clairement quelque chose dont j'ai besoin, donc je ne vais pas l'abandonner.
Tu en es probablement déjà conscient, mais je pense que le plus urgent à corriger est le fait que l’option --selector est ignorée : même avec --selector 1, ton script génère une empreinte sur le certificat entier et non sur la clef publique.
Après, autoriser les noms du RFC 7218 à la place des valeurs numériques (par exemple --selector Cert au lieu de --selector 0, --usage DANE-TA au lieu de --usage 2, etc.) serait plus user-friendly.
Pour l’intégration dans un fichier de zone, mon approche est la suivante : j’utilise un script qui se contente d’écrire l’empreinte sur sa sortie standard, et j’appelle ce script dans une macro M4 depuis mon fichier de zone. En quelque sorte c’est le fichier de zone qui va chercher la valeur dont il a besoin, plutôt que le script qui vient modifier le fichier de zone.
Concrètement, j’ai ça dans mon fichier de zone :
m4_define(SPKI_DIGEST, `m4_esyscmd(tls-key-mgmt spki-dgst -h 1ドル)')
[...]
_443._tcp.www.example.com. IN TLSA 3 1 1 SPKI_DIGEST(ee-web)
IN TLSA 3 1 1 SPKI_DIGEST(ee-web-next)
où tls-key-mgmt est mon script de gestion de clefs (appelé avec l’option spki-dgst, il renvoie l’empreinte de la clef publique spécifiée).
J’utilise une approche similaire pour les enregistrements DKIM et OPENPGPKEY.
Le fichier de zone est traité par M4 juste avant d’être envoyé à dnssec-signzone pour être signé.
Ce que j’apprécie dans cette approche est que le script gérant les clefs et calculant les empreintes n’a pas besoin de savoir quoi que ce soit à propos du fichier de zone, son seul rôle est de sortir les empreintes sans se soucier de ce qu’elles deviennent ensuite.
Cette indépendance me permet de réutiliser le même script pour insérer les empreintes dans le fichier de configuration d’Apache, pour la génération des en-têtes HPKP.
[^] # Re: Dépêche !
Posté par gouttegd . En réponse au journal Reparlons de Let’s Encrypt. Évalué à 4.
Tu en es probablement déjà conscient, mais je pense que le plus urgent à corriger est le fait que l’option
--selectorest ignorée : même avec--selector 1, ton script génère une empreinte sur le certificat entier et non sur la clef publique.Après, autoriser les noms du RFC 7218 à la place des valeurs numériques (par exemple
--selector Certau lieu de--selector 0,--usage DANE-TAau lieu de--usage 2, etc.) serait plus user-friendly.Pour l’intégration dans un fichier de zone, mon approche est la suivante : j’utilise un script qui se contente d’écrire l’empreinte sur sa sortie standard, et j’appelle ce script dans une macro M4 depuis mon fichier de zone. En quelque sorte c’est le fichier de zone qui va chercher la valeur dont il a besoin, plutôt que le script qui vient modifier le fichier de zone.
Concrètement, j’ai ça dans mon fichier de zone :
où
tls-key-mgmtest mon script de gestion de clefs (appelé avec l’optionspki-dgst, il renvoie l’empreinte de la clef publique spécifiée).J’utilise une approche similaire pour les enregistrements DKIM et OPENPGPKEY.
Le fichier de zone est traité par M4 juste avant d’être envoyé à
dnssec-signzonepour être signé.Ce que j’apprécie dans cette approche est que le script gérant les clefs et calculant les empreintes n’a pas besoin de savoir quoi que ce soit à propos du fichier de zone, son seul rôle est de sortir les empreintes sans se soucier de ce qu’elles deviennent ensuite.
Cette indépendance me permet de réutiliser le même script pour insérer les empreintes dans le fichier de configuration d’Apache, pour la génération des en-têtes HPKP.