Another Home Page Blog - certificathttps://blog.anotherhomepage.org/2017-01-16T09:30:00+01:00dehydrated, un client alternatif pour Let's Encrypt2017-01-16T09:30:00+01:002017-01-16T09:30:00+01:00Nils Ratuszniktag:blog.anotherhomepage.org,2017-01-16:/post/2017/01/16/dehydrated,-un-client-alternatif-pour-Let-s-Encrypt/<p>Après quelques galères avec <a href="https://github.com/certbot/certbot" title=""Certbot,">Certbot</a>, j'ai découvert <a href="https://github.com/lukas2511/dehydrated" title=""dehydrated,">dehydrated</a>, un client pour Let's Encrypt écrit en Bash.</p>
<p>Depuis plusieurs semaines, voire mois, le client officiel de l'autorité de certification Let's Encrypt, Certbot, ne fonctionne plus sous NetBSD. Cela semble venir du fait que Python, dont dépend Certbot, est compilé avec PaX …</p><p>Après quelques galères avec <a href="https://github.com/certbot/certbot" title=""Certbot,">Certbot</a>, j'ai découvert <a href="https://github.com/lukas2511/dehydrated" title=""dehydrated,">dehydrated</a>, un client pour Let's Encrypt écrit en Bash.</p>
<p>Depuis plusieurs semaines, voire mois, le client officiel de l'autorité de certification Let's Encrypt, Certbot, ne fonctionne plus sous NetBSD. Cela semble venir du fait que Python, dont dépend Certbot, est compilé avec PaX MPROTECT. C'est tout du moins ce qu'indique <a href="https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=51490" title=""NetBSD">ce rapport de bug</a>.</p>
<p>N'ayant ni le temps ni les compétences pour voir ce qui bloque exactement du côté de Certbot, j'ai fait ce que pas mal d'autres ont fait : j'ai recherché une alternative. La première alternative qui a attiré mon attention est <a href="https://kristaps.bsd.lv/acme-client/" title="acme-client">acme-client</a>, en version <a href="https://github.com/kristapsdz/acme-client-portable" title=""portable">portable</a>, d'ailleurs disponible au moment où j'écris ces lignes dans pkgsrc-wip. Mais en fait celui-ci ne semble pas fonctionner sous NetBSD, me hurlant des histoires de droits et de suid bizarres.</p>
<p>J'ai ensuite jeté mon dévolu sur dehydrated, un client écrit en Bash. Celui-ci a l'avantage non-négligeable de fonctionner, contrairement au précédent. Je me suis donc lancé dans son empaquetage (wip/dehydrated au moment où j'écris ces lignes, mais j'espère l'importer dans pkgrsc-current dès que possible). Dehydrated est assez pratique à utiliser, il nécessite des dépendances assez classiques pour un script shell (sed, awk, curl), en plus d'OpenSSL. Bien qu'il dispose de fichiers de configuration, de nombreuses options peuvent être spécifiées sur la ligne de commandes. Dehydrated prévoit aussi des scripts "hook" pour pouvoir déclencher d'autres actions avant et après le renouvellement d'un certificat par exemple.</p>
<p>Le paquet est globalement fonctionnel sous NetBSD, le seul prérequis avant de se lancer dans l'édition des fichiers de configuration est d'avoir une configuration OpenSSL existante (ce qui se fait rapidement, en copiant simplement le fichier d'exemple fourni dans <em>/usr/share/examples/openssl/</em>), et de savoir dans quel répertoire le challenge ACME sera déposé. J'espère d'ici là avoir amélioré la prise en compte d'OpenSSL d'ailleurs (utilisation de celui de pkgsrc par exemple). Idéalement, ce serait assez cool que dehydrated puisse utiliser <a href="https://www.libressl.org/" title="LibreSSL">LibreSSL</a>.</p>
<p>Il existe d'autres clients alternatifs que je n'ai pas essayés, comme <a href="https://github.com/srvrco/getssl" title=""obtain">getssl</a>, mais lequel est votre préféré et pourquoi ? Le formulaire de commentaire n'attend que votre réponse !</p>SSL à l'arrache, épisode 22016-12-28T09:30:00+01:002016-12-28T09:30:00+01:00Nils Ratuszniktag:blog.anotherhomepage.org,2016-12-28:/post/2016/12/28/SSL-à-l-arrache,-épisode-2/<p>Le premier épisode est <a href="/post/2008/07/19/SSL-a-l-arrache">ici</a>. En gros, je voulais rapidement générer un certificat SSL/TLS à des fins de tests.</p>
<p>Mais pourquoi un deuxième épisode ? Parce qu'il manquait quelque chose au premier, c'est la facilité d'automatisation. Alors bon, pour un site public, aujourd'hui, <a href="https://letsencrypt.org/" title=""Let's">Let's Encrypt</a> fait très bien le travail …</p><p>Le premier épisode est <a href="/post/2008/07/19/SSL-a-l-arrache">ici</a>. En gros, je voulais rapidement générer un certificat SSL/TLS à des fins de tests.</p>
<p>Mais pourquoi un deuxième épisode ? Parce qu'il manquait quelque chose au premier, c'est la facilité d'automatisation. Alors bon, pour un site public, aujourd'hui, <a href="https://letsencrypt.org/" title=""Let's">Let's Encrypt</a> fait très bien le travail et il vaut mieux se diriger vers cela. Mais dans le cas d'un site de tests, voire utilisé uniquement dans un LAN, c'est moins évident.</p>
<p>Retournons-donc à ce bon vieil <a href="https://www.openssl.org/" title="OpenSSL">OpenSSL</a> et à <a href="https://www.openssl.org/docs/man1.0.1/apps/openssl.html" title=""Page">sa page de manuel</a>. Les autres pages de manuel sont fort utiles, elles aussi. On peut alors arriver à une seule commande créant un CSR puis un certificat. En utilisant l'argument <em>-subj</em> on peut alors indiquer directement sur la ligne de commande les informations de type pays, province, ainsi que le <em>common name</em>. On peut d'ailleurs ajouter plusieurs noms en ajoutant plusieurs directives de type "CN".</p>
<p>Voici un exemple de création de certificat auto-signé, valable un an :</p>
<div class="highlight"><pre><span></span><code>openssl req -x509 -nodes -days 365 -newkey rsa:4096 \\
-keyout default.key \\
-out default.crt \\
-subj '/C=FR/ST=IdF/L=Paris/O=Example Org/OU=Dev/CN=example/CN=example.org/CN=www.example.org'
</code></pre></div>
<p>Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !</p>
<h2>Commentaires</h2>
<h3>Le 09/01/2017 10:33 par utux</h3>
<blockquote>
<p>Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !</p>
</blockquote>
<p>Oui, sous debian/ubuntu quand tu installe 'ssl-cert' (qui vient souvent avec ca-cert et openssl) tu as un certificat auto-signé (généré lors de l'installation). /etc/ssl/private/ssl-cert-snakeoil.key et /etc/ssl/certs/ssl-cert-snakeoil.pem</p>
<p>ça peut faire gagner un peu de temps :)</p>
<h3>Le 10/01/2017 09:31 par Nils</h3>
<p>Merci utux pour ta proposition !</p>
<p>Je suis allé jeter un oeil au paquet source <a href="https://packages.debian.org/source/sid/ssl-cert">ssl-cert</a>, et je ne suis pas totalement convaincu :</p>
<ul>
<li>d'abord, l'outil semble vraiment pensé uniquement pour Debian, dès le début, le script essaie de sourcer des fichiers spécifiques (/usr/share/debconf/confmodule) ;</li>
<li>ensuite, le fait qu'il ne semble utiliser que le nom d'hôte de la machine, il n'y a pas moyen d'utiliser un nom alternatif dans le script ;</li>
<li>enfin, la clé générée n'a une longueur que de 2048 bits ; on pourra néanmoins argumenter que cela est paramétrable, et que de toute façon c'est un certificat par défaut qui a pour but d'être temporaire.</li>
</ul>