Générer des certificats Let’s Encrypt *wildcard manuellement avec le client WACS sur Windows 10 ( et DNS-01 cloudflare)

Tous les 90 jours, je me retrouve dans la même situation de devoir renouveller mes certificats https Let’s Encrypt manuellement. Mes serveurs distants sont sur cPanel et l’hôte en question (namecheap) ne permet pas d’installer ACME sur les machines pour des raisons de marketing de leur propre produit SSL. L’accès SSH est très limité.

Donc, comme d’habitude, je générais les certificats sur ZEROSSL. Ceci étant fait, j’importait le .crt et la clé privée sur namecheap. Le processus était simple, mais cela fonctionnait très bien. Puis, ZEROSSL est passé en mode chiant, pardon, payant. On peut toujours générer des crt mais on est limité à 3. Il m’a semblé invraisemble de devoir payer pour avoir des .crt qui sont à la base gratos avec Let’s Encrypt. Il est vrai que les efforts de dev de l’UI ainsi que du client asme de ZEROSSL méritent compensantion, mais j’étais prêt à reprendre le contrôle sur le process.

Enter WACS

WACS veut dire « Windows ACME Simple ». C’est un client ACME qui tourne sur windows et permet une gestion quasi complète du processus de génération et renouvellement des certificats. Il est compris que ceci peut se faire par ligne de commande sur n’importe quelle distribution mais pour le commun de mortels, WACS est un client ergonomique, efficace et une excellente alternative aux clients web. Bon, faut quand même dire que c’est en English.

Passons aux choses sérieuses. On va créer un nouveau certificat pour un site web avec les propriétés suivantes :

  • Le site web est hébergé quelque part (on s’en fiche) et est fonctionnel sur n’importe quel port (80 ou 443 ou les deux),
  • On peut y importer des certificats (.crt) ainsi que notre clé privée (.key) de la façon qui nous enchante, en ligne de commande, par interface web, cPanel, Proxmox, ftp, etc.,
  • Le site est référencé dans le DNS de cloudflare et cela fonctionne déjà.

Pour résumer, nous allons donc effectuer une validation de notre site web par DNS (méthode DNS-01) et non pas par HTTP car nous n’avons pas une installation du client certbot sur le serveur lui même. Donc, même si (comme moi), vous avez votre port :80 fermé pour des raisons de sécurité, et/ou vous utilisez un reverse-proxy du type Traefik pour tout rediriger vers le port :443, ce ne sera pas un problème car la validation se fera par DNS uniquement.

Si vous avez déjà créé des champs TXT sur votre DNS pour effectuer des validations, c’est exactement le rôle du plugin de validation Cloudflare qui vous demandera un Token API afin d’automatiser le processus. Il vous supprimera aussi le champ TXT de votre DNS dès la validation terminée.

Etape 1:

On télécharge la dernière version de win-acme. ainsi que du plugin de validation DNS Cloudflare du sous-site sur Github ici, en bas de la page : https://github.com/win-acme/win-acme/releases/

Aperçu des paquets et plugins WACS sur Github

Vous pouvez aussi récupérez d’autres plugins pour effectuer les mêmes opérations sur d’autres hôtes.

Il faudra mettre le plugin là où se trouve votre wacs.exe.

Etape 2 :

On lance wacs.exe en administrateur de préférence pour qu’il ait accès aux répertoires afin de stocker les certificats. L’interface est propre, colorée, presque réconfortante 😉 On appréciera l’utilisation judicieuse des couleurs et une structure hiérarchique efficace pour gérer ses choix.

WACS 2.1 au lancement

Etape 3 :

On va partir dans l’option « M » afin de créer un certificat avec la possibilité de renseigner la méthode de validation. A savoir que « m » ça marche aussi bien que « M ». Bravo le/s programmeurs!

Choix « M » – Mode Interactif et Avancé

Je ne tourne pas sous IIS (Windows Server) et donc j’ai un warning, mais on s’en fiche.

Plus bas, j’ai le choix de générer mon certificat à partir d’un nouveau CSR où d’un CSR existant. Pour rappel, le Certificate Signing Request (CSR) rassemble essentiellement les noms des domaines à valider. C’est là où il faut pas se tromper si on veut valider notre nom de domaine (example.com) et tous les sous-domaines (*.example.com, dont www.example.com).

Je vais donc choisir « 2: Manual Input » car je n’ai pas de CSR déjà ou alors, je veux faire quelque chose de neuf. C’est l’option surligné par défaut en vert.

Etape 4 :

Je saisis les noms de domain qui m’interessent, donc déjà le wildcard de mon domain sous le format *.example.com. Cela couvrira tous les sous domaines, tels que mail.example.com, www.example.com, etc. Il faut aussi y inclure example.com, sinon la racine de mon site ne sera pas couvert par le certificat SSL :

*.example.com
example.com

Je fais « entrée » pour pousuivre vers la méthode de validation des noms que je viens de renseigner.

Etape 5 :

Dans cette étape, je vais signifier à WACS que je veux valider mon nom de domaine en passant par le DNS de Cloudflare. En gros, je lui dis « bon mon gars, c’est bien mes noms de domaine, je le jure. Mais si t’y crois pô, demande à mon DNS et il te le diras. La méthode charactérisant ce processus s’appelle « DNS-01 ». Donc je coche l’option « 6:  » dans le menu.

Si vous ne l’avez pas, c’est que le plugin DNS cloudflare est manquant, ou vous l’avez pas mis dans le même répertoire que wacs.exe. Donc, retour à l’étape 1!

On remarque aussi que les options « http-01 » sont grisées. C’est parce que je tente de valider un domaine un wildcard (*.example.com), ce qui signifie que je valide en vrac tous les sous-domaines de mon nom de domaine.

Et donc là, WACS me demande le Cloudflare API Token. Pour générer ce Token, il va falloir aller sur Cloudflare.

Etape 6:

Je génère donc un token personalisé sur Cloudflare en lui donnant un nom ludique et avec les autorisations suivantes :

Configuration du Token Personalisé

Perso, je copie le Token quelque part de sécurisé car c’est la seule fois qu’il apparaitra. Pour rappel, un token API est plus puissant qu’un mot de passe. On a même pas besoin de l’identifiant et on peut modifier directement les données d’un site/service rien qu’avec un token. Cloudflare émettait auparavant des tokens API globaux qui permettait tout (lecture, écriture) sur tous les sites du compte. Les « new token » sont là pour restreindre ces authorisations.

J’entre mon token API dans WACS

Etape 7 :

Je valide la clé en RSA (Option 2, par défaut).

Ensuite, je décide du choix de stockage de la clé en PEM car mes serveurs demandent de format (Apache, nginx).

Je renseigne aussi un endroit sur mon ordi pour stocker les certificats, et j’indique par la suite qu’on peut procéder.

Renseignements supplémentaires

La validation DNS se fait et après quelques tentatives (le logiciel se met en pauses de 30s pour permettre la propagation des donnés DNS), le certificat est généré et stocké là où on l’a spécifié sur notre ordi.

Création du Certificat

On peut dès lors quitter WACS et copier notre certificat et clé privé dans cPanel, ou d’autres services.

Fichiers générés: Chaine de certifs, certificat et clé privée.

Conclusion

Le logiciel WACS a bien plus de fonctionalités que ce qui a été utilisé dans ce tuto. Les renouvellements sont plus simples à effectuer ce qui nous laisse simplement l’étape de copier et de coller les certificats à jour aux bons endroits.

0 0 votes
Article Rating
S’abonner
Notification pour
guest

0 Commentaires
Commentaires en ligne
Afficher tous les commentaires
0
Nous aimerions avoir votre avis, veuillez laisser un commentaire.x