Journal Créer des certificats avec ACME/Let's Encrypt et des vérifications DNS

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
30
18
août
2016

Cher journal,

Voici une petite introduction à mon nouvel petit outil acme-dns-tiny qui me permet de demander à mon autorité de certification préférée de signer un certificat TLS automatiquement suite à des vérifications de ressources DNS et au moyen du protocol ACME.

L'outil a été crée depuis le projet père acme-tiny qui permet de faire la même chose, mais par vérification de liens HTTP.

Le but principal était de pouvoir créer des certificats sans avoir à perturber les services du serveur de production.
Un second but était de pouvoir exécuter ce script sur une autre machine que le serveur de production et sans accès root.
Enfin, comme son parent, un troisième but est d'être suffisamment court (~250 lignes) et restreint à la création de certificat pour être vérifiable rapidement.

Les deux premiers buts sont atteignables grâce aux possibilités de modification dynamique de ressources DNS à travers des messages DNS spécifiques et authentifiés avec un clé TSIG.

J'espère que cet outil pourra aussi être utile à toi ou à d'autres de tes amis.

Si tu trouves un bug ou que tu penses que le script peut être amélioré (sûrement ! c'est mon premier projet en python…), n'hésite pas à me le rapporter soit sur mon Gitlab, soit sur le mirroir Github, soit par email/xmpp à adrien@adorsaz.ch.

Merci de m'avoir lu et let's encrypt now !

  • # Excellent, une remarque

    Posté par  (site web personnel) . Évalué à 7.

    Bravo, c'est une très bonne idée. Juste une remarque, dans la page principale d'explications (Howto use), tu pourrais mentionner que ce que Let's Encrypt va demander de mettre comme enregistrement DNS, c'est le nom de domaine à certifier, préfixé de _acme-challenge, par exemple _acme-challenge.example.com. Ça permet de définir une autorisation de mise à jour dynamique plus stricte que ce que tu suggères, qui en pratique n'autoriserait la mise à jour que d'enregistrements de type TXT pour ce seul nom :

    key "_acme-challenge.example.com" {
    …
};

zone "example.com" {
    type master;
    file "example.com.zone";
    update-policy {
        grant _acme-challenge.example.com self * TXT;
    };
};

    À noter que, plutôt que d'authentifier la mise à jour dynamique par un secret partagé, il est possible d'utiliser une signature asymétrique pour cela, avec une paire de clefs SIG(0). C'est un peu plus compliqué, la clef publique devant être publiée dans la zone si je me souviens bien.

    • [^] # Re: Excellent, une remarque

      Posté par  (site web personnel) . Évalué à 6.

      La politique de mise à jour que je propose là est à mon style, il y a plein de façons de faire la même chose en pratique : personnellement, j'aime bien donner aux clefs le même nom que ce qu'elles servent à mettre à jour, d'où l'utilisation du type de nom self.

    • [^] # Re: Excellent, une remarque

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Merci pour les retours.

      En effet, je n'ai pas pensé à mettre l'information sur les ressources DNS vérifiées, je vais l'ajouter car c'est très important pour correctement configurer son serveur DNS.

      Pour l'update-ploicy, je vais aussi le mettre à jour dans l'exemple d'utilisation avec bind9. J'ai cherché un moyen pour créer une règle du style wildcard _acme-challenge.*.example.com, mais ce n'est pas possible.

      Du coup, comme j'avais le nez dans ce problème, je n'ai pas pensé à chercher des solutions plus simples. Le problème de self est qu'il oblige à utiliser des CSR avec un seul domaine (et donc de faire un CSR et une configuration acme-dns-tiny par domaine à vérifier).

      Je pense que je vais plutôt montrer un exemple de ce style:

      key "_acme-challenge" {
    …
};

zone "example.com" {
    type master;
    file "example.com.zone";
    update-policy {
        grant _acme-challenge name _acme-challenge.example.com TXT;
        grant _acme-challenge name _acme-challenge.www.example.com TXT;
    };
};

      C'est un peu moins rapide à mettre en place que zonesub s'il y a beaucoup de sous-domaines à vérifier, mais c'est beaucoup plus sécurisé car les autorisations sont restreintes au minimum.

      Merci pour SIG(0), je ne connaissais pas ce protocole. Malheureusement, le module dnspython que j'utilise ne l'implémente pas : https://groups.google.com/forum/?hl=fr#!topic/dnspython-users/ZnssFZlA48o

Suivre le flux des commentaires

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