Archives par étiquette : letsencrypt

Let’s Encrypt… sur ESXi

Hoplà, j’en avais marre d’avoir des certifs auto-signés sur mes ESXi. Surtout depuis la mise en place de HSTS sur des domaines entiers (je vais tâcher de pondre un rapide article sur HSTS prochainement), les navigateurs hurlaient en voyant l’interface web (en https, donc) de ESXi présenter des certifs auto-signés. Il fallait désactiver HSTS sur ces sites au niveau du serveur web ou le court-circuiter pour ces sites au niveau du navigateur ou trouver une autre solution… Continuer la lecture

smtp et imap via SSL/TLS + let’s encrypt

Petit aide mémoire et astuces pour avoir des certificats qui vont bien dans un environnement postfix/dovecot ; et non pas des certif auto-signés comme vous avez peut-être.

Dernièrement, en voulant configurer un iFoune pour atteindre un serveur de mails à moi (tournant sur postfix/dovecot), j’ai vu que l’option « accepter tous les certificats » n’était plus de ce monde. Peut-être que Appeul a décidé que le SSL étant tellement basique maintenant, il n’y avait plus aucune raison d’avoir des certificats moisis (par exemple ceux auto-signés qu’on a à la création d’un postfix/dovecot). C’est pas faux.

Sauf que ça me faisait suer, car j’avais gardé en tête que postfix ne sait pas gérer du multi-certificats Continuer la lecture

letsencrypt & wildcard : « dehydrated » et challenge DNS

Bon, je devais m’y mettre pour un site web pour lequel j’avais besoin d’un certificat wildcard. Jusqu’à présent, j’en prenais chez un acteur connu du marché, pour environ 100 € / an.
Pour les autres domaines que je gère, j’utilisais déjà letsencrypt avec le client dehydrated qui fait le boulot simplement.

Depuis que « let’s encrypt » sait gérer les certificatfs wildcard (*.domaine.tld), je ne vois plus bien de raison de continuer à payer ce certificat. C’est pas comme si letsencrypt était une boîte vouée à la fermeture. Quand on voit qui la soutient, c’est bon.

En gros, la gestion des certifs « wildcard » ne change pas grand chose au bazar, c’est juste l’outillage qui est sensiblement différent. En effet souvent lorsqu’on met en place dehydrated (ou un autre), on répond aux « challenges » (procédé pour vérifier que vous êtes bien le propriétaires annoncé d’un site) en faisant placer un fichier par le client dehydrated dans un sous-répertoire style « acme-challenge » sur le serveur web. letsencrypt vérifie alors que ce fichier est récupérable, ça prouve que vous avez la main sur le site (selon où il est censé être vu la conf DNS), ça génère les certificats et zou.

Pour les wildcards, le challenge par http n’est pas possible Continuer la lecture