Imprimer

[alex]

     

Tuto, Let's Encrypt : Obtenir un certificat de sécurité Wildcard sous Windows ou Linux avec acme.sh et CloudFlare ou ISPConfig

Mise à jour : 8 octobre 2021
- Mise à jour du tuto suite à la fin de vie du certificat racine DST Root CA X3 au profit de ISRG Root X1.
- Mise à jour également afin d'éviter l'utilisation de acme.sh avec ZeroSSL comme autorité de certification.
- Dernière mise à jour pour l'API ISPConfig de acme.sh et l'erreur "Client ID is not numeric".

Quelques captures écran ont également été mises à jour afin de coller à la réalité d'aujourd'hui.

Mise à jour du 17 juillet 2020
ATTENTION aux utilisateurs de Freenom !
Cloudflare n'autorise plus les domaines gratuits de Freenom ! (.cf, .ga, .gq, .ml et .tk)
Vous obtiendrez systématiquement une erreur même si vous avez un domaine Freenom géré par Cloudflare ajouté avant l'interdiction.

Mise à jour : 07 novembre 2018
Un exemple pour un système de gestion de serveur a été ajouté. Il s'agit de ISPConfig qui, théoriquement, n'a pas besoin de CloudFlare.

Introduction
Utilisateurs Windows, installer Cygwin
Utilisateurs Windows, installer les paquets requis par acme.sh
Confier la gestion de notre domaine à CloudFlare
Obtenir la clé API de notre compte CloudFlare
Installer acme.sh
Préparons maintenant le fichier API de Cloudflare
Acme.sh et le CA ZeroSSL, changer pour LetsEncrypt
Obtenir un certificat wildcard "classique" à base de clés RSA
Obtenir un certificat wildcard à base de clés ECDSA
Renouvellement du certificat
Révoquer le certificat
Avantages et inconvénients des clés RSA et ECDSA

Comment utiliser une autre API que celle de Cloudflare ? Exemple avec ISPConfig
ISPConfig et l'erreur "Client ID is not numeric"

Expiration de la racine DST Root CA X3 (seulement si vous avez des problèmes !)



(Haut de Page)
- Introduction

Avant toute chose, retenez bien cette adresse : https://www.ssllabs.com/ssltest/
Ce site vous permettra de tester votre configuration SSL. Je compte sur vous pour obtenir un A+ !

Dans ce nouveau tuto dédié aux certificats de sécurité, nous allons nous pencher sur l'obtention d'un certificat de sécurité wildcard à l'aide de l'utilitaire acme.sh et les serveurs DNS de Cloudflare.
Acme.sh est un utilitaire Bash permettant d'obtenir des certificats SSL qui a l'énorme avantage de proposer des dizaines d'API DNS prévues pour les principaux registrars (OVH, Gandhi, GoDaddy, etc.), gestionnaires serveurs et hébergeurs. Plus de 50 API sont au programme à l'heure où j'écris et d'autres sont en préparation, c'est donc le diable si vous ne trouvez pas la votre !
Dans l'éventualité où vous ne trouveriez pas l'API adéquate, nous utiliserons les serveurs DNS de Cloudflare, avec un compte gratuit, auxquels il faudra confier la gestion du domaine pour lequel nous souhaitons un certificat.
Pas de panique ! Il ne s'agit pas de transférer votre domaine vers CloudFlare, mais juste lui confier la gestion du domaine, ce qui est une manœuvre réversible.

Cette fois, c'est un certificat wildcard que nous allons créer. Un certificat wildcard est prévu pour un nombre illimité de sous domaines, même si ils n'existent pas à la création du certificat.
Un certificat wildcard utilise le caractère générique, ou wildcard en anglais, pour couvrir tous les sous domaines. Ce caractère générique ou wildcard est tout simplement l'astérisque ( * ).
Exemple :
Domaine : example.com
Sous domaines : *.example.com

Pour ce faire, nous utiliserons donc le petit utilitaire acme.sh qui est d'une utilisation très simple.
Les utilisateurs Windows devront installer Cygwin afin de pouvoir émuler une espèce de Linux sur leur ordinateur (un bash plus précisément). Ne prenez pas peur, ce tuto vous aidera à installer Cygwin.
Quant aux utilisateurs Linux, vous n'aurez quasiment rien à faire, si ce n'est installer acme.sh.

Cerise sur le gâteau, pour les curieux ou paranos de la sécurité, nous demanderons 2 types de certificat.
Nous demanderons d'abord un certificat "classique" à base de clés RSA.
Ensuite, nous demanderons un certificat à base de clés ECDSA s'appuyant sur les courbes elliptiques. Vous verrez que ce type de clé est très robuste malgré une très petite longueur de clé (comparé à RSA).




(Haut de Page)
- Utilisateurs Windows, installer Cygwin

Sous Windows, nous n'avons pas le choix, il nous faut installer un émulateur bash. Un émulateur bash est tout simplement un programme qui imite le fonctionnement de la ligne de commande Linux. Vous aurez un écran noir qui attend vos ordres, comme dans une fenêtre de ligne de commande MS-DOS.
Pour info, la ligne de commande s'appelle console.
Pour imiter (émuler) la console Linux, nous allons donc installer Cygwin.

Commençons de suite, téléchargeons Cygwin ! (Vous placerez votre téléchargement sur le bureau, il ne va pas y rester longtemps)
Si vous avez un Windows 64bit, c'est ici : https://cygwin.com/setup-x86_64.exe
Si vous avez un Windows 32bit, c'est ici : https://cygwin.com/setup-x86.exe

C'est tout, vous avez tout ce qu'il faut !
Maintenant, nous allons créer le dossier de Cygwin afin qu'il soit utilisable sans souci.
Sur votre disque C:, créez un dossier C:\cygwin.
Ensuite, créez un dossier C:\cygwin\_install ou allez dans le dossier C:\cygwin. et créez le dossier \_install.
Dans ce dossier C:\cygwin\_install, placez le programme téléchargé précédemment.
Je vous conseille vivement de créer un raccourci sur votre bureau vers ce programe (clic droit + envoyer vers le bureau). Vous en aurez besoin très souvent !

Vous êtes prêt ? Les chemins sont créés et le programme d'installation Cygwin est placé où il faut ? Allons-y !
Double cliquez sur le raccourci que vous avez créé sur le bureau ou rendez-vous dans C:\cygwin\_install et ouvrez le programme présent. Ah je vous ai prévenu ! Il est préférable de placer un raccourci sur le bureau. C'est la première fois que vous utilisez le programme d'installation, mise à jour, suppression de Cygwin, mais ce n'est certainement pas la dernière !


Une fenêtre va s'afficher à vous, Cliquez sur suivant. :



Là, sélectionnez "Install from Internet" et cliquez sur suivant.



Maintenant, faites attention. choisissez le dossier de Cygwin, c'est à dire le dossier de votre Linux émulé. Ce dossier sera C:\cygwin que vous avez déjà créé. Cliquez sur suivant.



Ensuite, sélectionnez le dossier contenant le programme d'installation de Cygwin. Pour nous, ce dossier est C:\cygwin\_install et on clique sur suivant.
Ne vous inquiétez pas, vos choix seront mémorisés. La prochaine fois, les champs seront déjà pré-remplis.




La fenêtre qui suit peut être ignorée dans la plupart des cas sauf sous Windows 10 !. Si c'est votre cas, cochez la case "Direct Connection".
Cliquez sur suivant.





Le sérieux commence !
(Haut de Page)
- Utilisateurs Windows, installer les paquets requis par acme.sh

Si vous commencez le tuto ici, lancez le programme d'installation de Cygwin. Vous avez normalement créé un raccourci sur le bureau. Avancez jusqu'à la fenêtre de sélection de proxy.
Pour les autres, ceux qui ont commencé à installer Cygwin, on continue.

Il va vous être demandé de choisir un serveur de téléchargement pour les paquets que vous voudrez installer et les mises à jour.
Choisissez le serveur FTP le plus proche de chez vous. A Marseille, le plus proche est l'Allemagne...
Votre choix sera mémorisé. Lors de votre prochaine visite du programme d'installation de Cygwin, les chemins et serveurs seront déjà affichés.




Enfin, nous arrivons sur la fenêtre d'installation des paquets Cygwin !
Sélectionnez la vue "Not installed" et commençons notre choix des paquets nécessaires à Cygwin.
Dans le champs "Search", entrez "Curl". Sur la liste qui s'affiche, choisissez la catégorie "Net" et sélectionnez la dernière version.
Cherchez ensuite le paquet "Wget" dans la catégorie "Web". Les deux paquets "Curl" et "Wget" sont nécessaires, il peut arriver que "Curl" marche mal, notamment si vous êtes sous Windows 10.
Recommencez en cherchant le paquet "Socat" dans la catégorie "Net, Utils".
Encore un dernier paquet. Cherchez "Cron" dans la catégorie "Admin", c'est le paquet "Cron: Vixie's cron" qui s'affichera.
Pour tous ces paquets, sélectionnez la dernière version en cliquant dans le menu des versions proposées.
Une fois terminé avec tous les paquets à installer, cliquez sur "suivant".




Cygwin va installer les paquets souhaités et il vous affichera une dernière fenêtre.
Créez au moins une icône sur le bureau. C'est cette icône qui vous permettra de lancer Cygwin.




Vous devriez donc avoir 2 icônes sur le bureau.
Une icône vous permettant de lancer le programme d'installation/mise à jour de Cygwin et une autre vous permettant de lancer Cygwin (vous pouvez essayer cette seconde icône, une fenêtre Linux s'ouvrira).




Dorénavant, lorsque vous cliquerez sur l'icône d'installation, des mises à jour vous seront proposées si elles existent. Installez toujours ces mises à jour.





(Haut de Page)
- Confier la gestion de notre domaine à CloudFlare

Maintenant, il va falloir que nous utilisions des DNS pour lesquels acme.sh propose une API. Nous allons donc utiliser les DNS de Cloudflare.
Encore une fois, ne vous inquiétez pas, il ne s'agira pas de transférer votre domaine à CloudFlare, vous en resterez propriétaire. Nous utiliserons simplement leurs serveurs DNS, c'est tout.
Rendez-vous sur la page d'accueil de Cloudflare, https://www.cloudflare.com/fr-fr/. Créez un compte si vous n'en possédez pas, sinon connectez vous.

Ensuite, cliquez simplement en haut à droite de la fenêtre sur Add site :




Dans la fenêtre qui se présente à vous, entrez votre domaine et validez :




Cloudflare devrait vous indiquer qu'il va récupérer les enregistrements DNS de votre domaine et vous pouvez passer à la suite :



Sur la fenêtre qui suit, sélectionnez le plan gratuit et confirmez.

La fenêtre suivante vous indiquera les enregistrements DNS que Cloudflare a réussi à récupérer.
Observez attentivement cette page et notez les enregistrements que vous devrez recréer.
Vous pouvez recréer immédiatement les enregistrements manquants en utilisant le champ en haut de page (2).



ATTENTION, SOYEZ VIGILANT !
Lorsque vous créez vos enregistrements, et sur ceux récupérés, un petit nuage et une flèche apparaissent à droite (1 & 3) :
Cliquez sur ces nuages pour qu'ils s'affichent avec la flèche qui contourne le nuage :

Si ce n'est pas fait, toutes vos données transiteront par les serveurs de Cloudflare qui se comportera comme un proxy entre vous, vos visiteurs et votre site.
Ici, nous voulons simplement un service DNS, c'est tout, pas toute la panoplie d'outils d'espionnage fournis gracieusement par Cloudflare. Il aura déjà toutes les requêtes DNS à se mettre sous la dent, ça suffit largement !



C'est terminé ? Alors validez.
Maintenant, Cloudflare va vous demander de changer les serveurs DNS de votre domaine pour les remplacer par les siens.




Cette étape est propre à chaque registrar. Rendez-vous dans votre espace client chez votre registrar et modifier les DNS par ceux indiqués par Cloudflare. Si votre registrar n'a pas prévu la possibilité de désactiver/activer ou restaurer les DNS par défaut, notez les dans un coin où ils ne seront pas perdus.

Par exemple, chez Freenom avec un domaine gratuit, cela se présente tout bêtement.




Une fois que c'est fait, continuez.
C'est maintenant l'étape la plus longue. Cloudflare va s'assurer que les DNS ont correctement été changés.
Tant que la propagation DNS ne sera pas complète, ou en partie, vous ne pourrez pas aller plus loin.
Vous pouvez revérifier cette propagation aussi souvent que vous le souhaitez.




Ca y est, c'est bon ? Cloudflare à la main sur votre domaine ? Continuons !
Maintenant, cliquez sur Home, sélectionnez votre domaine (ou site), en haut de page puis cliquez sur le bouton Overview.




Sur la page affichée, vous verrez que Cloudflare active par défaut 2 services qui sont totalement inutiles.




Cliquez sur le Medium de Security level et sélectionnez Essentially off.



Puis, revenez au début en cliquant le bouton Overview ou re-sélectionnez votre domaine.
Maintenant, cliquez sur le Full de SSL et sélectionnez OFF.




Revenez au début en cliquant le bouton Overview.
Votre domaine se présente comme sur l'image ci-dessous ?




Tout est ok ? Ouf, le plus emmerdant est fait !
Il ne reste plus qu'à récupérer la clé API de votre domaine.




(Haut de Page)
- Obtenir la clé API de notre compte CloudFlare

Le temps de récupérer notre clé API pour pouvoir utiliser acme.sh et nous en aurons terminé avec ce foutu Cloudflare.

Sélectionnez n'importe quel domaine en haut de la page Cloudflare et cliquez sur le bouton Overview.




Là, cliquez sur le lien Get your API key.




A présent, en bas de page, cliquez sur View de la ligne Global API key.




Votre mot de passe vous sera demandé et il vous faudra résoudre le captcha de Google. Enfin, validez.




Et enfin, la voilà ! Votre clé API s'affiche.



Copiez/collez cette clé dans un endroit sûr, nous allons la réutiliser avec acme.sh
ATTENTION ! Cette clé API est aussi secrète qu'un mot de passe. Elle permet un accès complet à votre ou vos domaines !




(Haut de Page)
- Installer acme.sh

Vous installez acme.sh pour la première fois ? Passez directement au 2, la suite ne vous concerne pas.

1) La version 3.0.1 de acme.sh prend en compte l'expiration du certificat racine LetsEncrypt DST Root CA X3.
Si vous avez des problèmes avec un certificat qui veut utiliser cette racine, mettez à jour acme.sh afin de pouvoir utiliser le certificat racine ISRG Root X1.
Ensuite, renouvelez ou re-créez votre certificat afin qu'il utilise cette nouvelle racine en utilisant le paramètre supplémentaire --set-default-chain lors du renouvellement/re-fabrication de votre certificat.


2) Pour les utilisateurs Windows, lancez Cygwin. Attention ! Si vous possédez Windows 10, lancez Cygwin en mode administrateur (clic droit sur l'icône suivi de "Exécuter en tant qu'administrateur").
Les utilisateurs Linux ouvriront la console.

Installer acme.sh est relativement simple. Il est recommandé d'avoir les permissions root mais ce n'est pas nécessaire.
Si vous utilisez Cygwin, rassurez-vous, vous n'êtes pas concerné par les permissions de groupes.

Avec les permissions root, le dossier /root sera utilisé. Sinon, il s'agira de votre dossier utilisateur ~ ($HOME).
Entrez donc

Code

cd /root

ou

Code

cd ~

Selon les permissions que vous possédez.


Pour installer simplement acme.sh, les utilisateurs Cygwin et Linux entreront :

Code

curl https://get.acme.sh | sh

Vous pouvez également utiliser Wget si vous avez des soucis avec cURL :

Code

wget -O -  https://get.acme.sh | sh

Et voilà, acme.sh est installé ! Simple, non ?

Pour être certain que acme.sh est exécutable, entrez ce qui suit : (la plupart du temps, le fichier est déjà exécutable, mais il peut arriver qu'il ne le soit pas selon l'OS utilisé et les permissions accordées lors de l'installation)

Code

chmod +x .acme.sh

Et maintenant, essayez donc :

Code

acme.sh

Vous devriez obtenir l'aide de acme.sh à l'écran.


Votre installation de acme.sh a créé 3 choses :

• Une copie de acme.sh dans le dossier ~ ou /root (c'est un fichier caché)
• La création d'un alias acme.sh dans le dossier ~/.acme.sh/ ou /root/.acme.sh/
• La création d'une tâche cron permettant de renouveler vos certificats existants automatiquement.

Pour mettre à jour acme.sh, vous entrerez :

Code

acme.sh --upgrade

Ou pour que acme.sh se maintienne automatiquement à jour :

Code

acme.sh --upgrade --auto-upgrade

ATTENTION !
Le dossier de acme.sh est .acme.sh/ ! C'est donc un dossier caché !
Notez le bien, sinon vous risquez de tourner en rond à la recherche vos certificats.



(Haut de Page)
- Préparons maintenant le fichier API de Cloudflare

Ouvrez en édition, le fichier ./.acme.sh/dnsapi/dns_cf.sh

Le début du fichier ressemble à ceci :

Code

#!/usr/bin/bash

#
#CF_Key="sdfsdfsdfljlbjkljlkjsdfoiwje"
#
#CF_Email="xxxx@sss.com"

Retirez les commentaires (#) devant les lignes CF_KEY et CF_Email.
Ensuite, remplacez le contenu entre guillemets par votre clé API et votre E-mail de compte Cloudflare.

Vous obtiendrez quelque chose de similaire à ceci :

Code

#!/usr/bin/bash

#
CF_Key="46dfqdf465qf456qsf4qsd87"
#
CF_Email="mon_email@example.com"

Lors de l'exécution de acme.sh avec l'API Cloudflare, ces paramètres seront exportés vers le fichier ./.acme.sh/account.conf
De cette façon, si une mise à jour venait à réinitialiser ce fichier, vos paramètres ne seront pas perdus pour acme.sh qui pourra les réutiliser pour les renouvellements ou un nouveau certificat utilisant cette même API.


(Haut de Page)
- Acme.sh et le CA ZeroSSL, changer pour LetsEncrypt

A partir de la version 3.0.0, acme.sh a eu cette drôle d'idée de désigner comme autorité de certification par défaut, ZeroSSL.
Le but du jeu est d'obtenir un certificat LetsEncrypt, pas ZeroSSL !
Cela ne concerne que les personnes procédant à une première installation ou réinstallation de acme.sh. Les autres, ayant mis à jour, garderont leur configuration.

Avec les paramètres par défaut (et donc ZeroSSL) si vous demandez un certificat, ZeroSSL vous obligera à fournir un mail et il stoppera acme.sh.




Que faire ? Bien entendu, si vous fournissez un mail, aucun abus ne sera commis avec. Vous ne recevrez des mails qu'en cas de souci avec votre certificat, rien d'autre.
Mais cette obligation est gênante quand même ! Fournir un mail, je veux bien et je le fais toujours. Etre obligé de fournir ce mail sinon je n'aurai pas mon certificat, là ça m'agace...
Il faut donc demander à acme.sh de changer de CA par défaut. Pour info, un CA est une autorité de certification (Certificate Authority).

Demandons donc à acme.sh d'utiliser LetsEncrypt comme CA par défaut et personne d'autre :

Code

acme.sh --set-default-ca --server letsencrypt

Et voilà qui est fait, acme.sh devrait vous afficher le message suivant :




Vous avez reçu ce message ? Alors c'est tout bon, vous pouvez continuer vers l'obtention de votre certificat.
ATTENTION !
Cette manip n'est valable qu'à partir de la version 3.0.0 de acme.sh. Avant cette version, vous recevrez un message d'erreur.



(Haut de Page)
- Obtenir un certificat wildcard "classique" à base de clés RSA

Obtenir un certificat wildcard à base de clés RSA est tout aussi simple que d'installer acme.sh

Pour obtenir un certificat wildcard pour le domaine example.com, nous entrerons :

Code

acme.sh --issue -d example.com -d *.example.com --dns dns_cf

Le paramètre --dns dns_cf demande une validation DNS en utilisant l'API de Cloudflare.

Vous verrez que acme.sh crée 2 enregistrements DNS TXT pour votre domaine et qu'il attend ensuite 2 minutes le temps de la propagation DNS.
Ensuite, Lets Encrypt lira ces enregistrements pour validation, acme.sh les supprimera et vous obtiendrez votre certificat !

Votre certificat, le certificat intermédiaire (le bunddle) et sa clé se trouveront dans le dossier ./.acme.sh/example.com/
Ne supprimez rien dans ce dossier ! acme.sh à besoin du contenu de ce dossier pour les renouvellements automatiques.




(Haut de Page)
- Obtenir un certificat wildcard à base de clés ECDSA

Un autre type de certificat est disponible avec acme.sh et Lets Encrypt.
Il s'agit des certificats à base de clés ECDSA s'appuyant sur les courbes elliptiques. Malgré une faible longueur, ces clés sont très robustes.

Lets Encrypt reconnait les courbes elliptiques P-256 et P-384. Le P-521 n'est pas encore reconnu.

Nous procéderons de la sorte pour obtenir un certificat Wildcard utilisant ce type de clé :

Code

acme.sh --issue -d example.com -d *.example.com --keylength ec-384 --dns dns_cf

Le paramètre --dns dns_cf demande une validation DNS en utilisant l'API de Cloudflare.

Vous verrez que acme.sh crée 2 enregistrements DNS TXT pour votre domaine et qu'il attend ensuite 2 minutes le temps de la propagation DNS.
Ensuite, Lets Encrypt lira ces enregistrements pour validation, acme.sh les supprimera et vous obtiendrez votre certificat !

Votre certificat, le certificat intermédiaire (le bunddle) et sa clé se trouveront dans le dossier ./.acme.sh/example.com_ecc/
Ne supprimez rien dans ce dossier ! acme.sh à besoin du contenu de ce dossier pour les renouvellements automatiques.




(Haut de Page)
- Renouvellement du certificat

Si vos renouvellements ne se font pas automatiquement, vous pouvez le faire manuellement, toujours très simplement.
Prenons l'exemple avec notre domaine example.com :

Code

acme.sh --renew -d example.com

Vous pouvez forcer le renouvellement si la validité restante du certificat est supérieure à 30 jours :

Code

acme.sh --renew -d example.com --force

Pour les certificats à clés ECDSA, le renouvellement sera sous cette forme :

Code

acme.sh --renew -d example.com --ecc

Ou en forçant le renouvellement :

Code

acme.sh --renew -d example.com --force --ecc

Vous aurez remarqué qu'il n'est pas utile d'indiquer tous les domaines et sous domaines. Seul le premier domaine indiqué à la création du certificat, le domaine que acme.sh utilise pour nommer les dossiers et fichiers, est nécessaire.



(Haut de Page)
- Revoquer le certificat

Révoquer un certificat restera tout aussi simple, vous l'aurez compris :

Code

acme.sh --revoke -d example.com

Ou, si à base de clés ECDSA :

Code

acme.sh --revoke -d example.com --ecc

(Haut de Page)
- Avantages et inconvénients des clés RSA et ECDSA

- Les clés RSA sont connues de quasiment tout le monde et simples à manipuler.
- Elles sont prises en charge par tous les softs utilisant la cryptographie.

- Malheureusement, le temps passant, il est nécessaire de générer des clés de plus en plus longues.
- La longueur des clés RSA n'est pas sans retentissement sur les performances d'un système.


- Les clés ECDSA sont très courtes (comparé à RSA) et sont pourtant très robustes, bien plus robustes que RSA.
Pour comparaison, une clé ECDSA 256 bit est équivalente à une clé RSA 3072 bit, et une clé ECDSA 384 bit est équivalente à une clé RSA 7680 bit !
- Tout comme RSA, la longueur des clés ECDSA évolue. Mais cette évolution est bien moins importante que RSA. Il semblerait donc que RSA n'ait pas un très grand avenir comparé à ECDSA qui pourrait être la solution.

- Le plus gros problème des clés ECDSA est qu'elles ne sont pas prises en charge par des softs anciens ayant court sur de nombreux systèmes comme Postfix et Dovecot, ce qui est un gros problème...




(Haut de Page)
- Comment utiliser une autre API que celle de Cloudflare ? Exemple avec ISPConfig

C'est toujours très simple. Vous l'avez compris, acme.sh est très simple d'utilisation.

Imaginons que vous avez un serveur géré par ISPConfig.
Sur ce serveur, vous avez installé votre propre DNS et vous n'avez pas besoin de Cloudflare.

Tout d'abord, rendez vous sur votre compte ISPConfig et créez un compte distant pour que l'API puisse faire son boulot.
Ce compte possédera les autorisations minimums nécessaires à acme.sh
Dans Système, choisissez "Utilisateurs distants" et cliquez sur "Ajouter un utilisateur".





Là, vous êtes seul maitre à bord. Choisissez un nom et un mot de passe solides.
A cet utilisateur distant, autorisez les permissions suivantes :

• Fonctions Zone DNS
• Fonctions TXT DNS

Cochez la case Remote Access (accès distant)
Sous cette case, vous pouvez restreindre l'accès à des IP ou noms de domaine.
Les anciennes version de ISPConfig ne permettent pas tout ça, mais ce n'est pas important pour faire fonctionner acme.sh. Souvenez-vous d'utiliser un identifiant et un mot de passe solides !





Et voilà, l'API de acme.sh est prête à accéder à votre serveur.

Ouvrez le fichier API de ISPConfig afin de l'éditer.
Le fichier API se trouve dans ./.acme.sh/dnsapi/dns_ispconfig.sh

Le début du fichier ressemble à ceci :

Code

#!/usr/bin/bash

# ISPConfig 3.1 API
# User must provide login data and URL to the ISPConfig installation incl. port. The remote user in ISPConfig must have access to:
# - DNS txt Functions

# Report bugs to https://github.com/sjau/acme.sh

# Values to export:
# export ISPC_User="remoteUser"
# export ISPC_Password="remotePassword"
# export ISPC_Api="https://ispc.domain.tld:8080/remote/json.php"
# export ISPC_Api_Insecure=1     # Set 1 for insecure and 0 for secure -> difference is whether ssl cert is checked for validity (0) or whether it is just accepted (1)

Dé-commentez (retirez les #)  et remplacez les lignes suivantes par vos données de connexion ISPConfig :

• ISPC_User: Votre nom d'utilisateur distant.
• ISPC_Password : Votre mot de passe pour ce compte distant.
• ISPC_Api : L'adresse du script ISPConfig qui va gérer votre communication, par exemple, https://example.com:8080/remote/json.php.

Ce script est à sa place, il n'en n'existe pas d'autre. Gardez le chemin /remote/json.php !

• ISPC_Api_Insecure : Si la valeur est de "1", une connexion sécurisée sera utilisée mais le certificat ne sera pas vérifié, il sera juste utilisé pour chiffrer la connexion (c'est parfait pour les certificats auto signés).
  Sinon, à "0", la validité du certificat sera vérifiée et tout sera stoppé si un problème de validité se présente.

Attention ! Il n'est pas envisageable d'utiliser une connexion non sécurisée. Ca ne marcherait pas.
Avec ISPConfig, la mise en place d'une connexion SSL à base de certificat auto signé est le minimum !




(Haut de Page)
- ISPConfig et l'erreur "Client ID is not numeric"

Il semblerait que certains hébergeurs "bricolent" ISPConfig et l'API DNS de acme.sh afin que des ID exclusivement numériques soient utilisés. Une abberation en matière de sécurité mais simple à gérer !..

Certains utilisateurs de acme.sh pensent apporter une amélioration en copiant/collant le code de leur hébergeur sur le dépôt Github de acme.sh. Quelle erreur ! Le pire est que ce code ne semble pas être vérifié puisqu'il se retrouve à chaque fois dans un commit suivi d'une mise à jour de acme.sh...

Et après chaque mise à jour, vous vous retrouvez avec une erreur qui semble incompréhensible quand on ne connait pas le pourquoi du comment :
Client ID is not numeric !

La solution est aussi simple et rapide que radicale. Il faut remplacer l'API DNS de acme.sh pour ISPConfig.
Votre serviteur a pensé à vous et possède cette API "propre" sur son compte Github.
Téléchargez le fichier API dns_ispconfig.sh à cette adresse : https://github.com/alexetgus/acme.sh_api_ispconfig/releases/download/1.0/dns_ispconfig.sh

Lorsque vous avez ce fichier, placez-le dans le dossier ~/.acme.sh/dnsapi/ et écrasez le fichier existant lorsque la question vous est posée.
Inutile de réfléchir, le fichier API existant est une saleté qui ne marche pas. Remplacez-le par le nouveau fichier !

Une fois que c'est fait, vous pouvez ré-utiliser acme.sh comme au premier jour !
Le dépôt Github de ce fichier est ici si vous souhaitez le regarder avant de l'installer : https://github.com/alexetgus/acme.sh_api_ispconfig

[alex]

Une première mise à jour fait son apparition et concerne ISPConfig.

[maximus23]

Bonjour,

Voilà testé sur Ubuntu avec Cloudfare via Gandi pour mon domaine de test forum-informatique.org.

Certficat Wilcard Ok.

Dis moi ce que tu as comme cypher pour moi voir en comparaison.

[alex]

Tu as réussi, bien !
C'est super simple, n'est-ce pas ? Tout est indiqué dans les fichiers API.

Tu veux les ciphers de où ?
Ceux de chez oim ou ceux de mon local ?


Quand j'y pense, j'ai oublié de donner une adresse indispensable pour tester son installation SSL, je vais corriger ça.
C'est ici : https://www.ssllabs.com/ssltest/

[maximus23]

Là c'est pas du local tu sais voir ma config cypher avec le test ssl labs.

Attention une chose assez déroutante pour les non initiés c'est que le répertoire est caché avec tout ses fichiers y compris les fichiers qui servent pour les certificats SSL.

Donc peut-être mettre une commande directe via VIM ou autre trucs pour éditer et après ils doivent absolument récupérer les chemins indiqués par putty ou autre ligne de commande sinon ils ne les retrouveront plus.

La commande

Code

chmod +x .acme.sh 

ne la met pas en option car on doit rendre exécutable acme donc il vaut mieux la mettre dans le déroulement des opérations.

Sinon rien à dire pour Cloudfare et acme c'est enfantin avec ton tuto

[alex]

Fais attention, tu ne devrais plus autoriser TLSv1, ce protocole n'est plus jugé comme sûr.
Enfin, c'est toi qui voit.
Pareil pour les ciphers, il faut désactiver les ciphers avec échange de clés s'appuyant sur RSA, c'est des ciphers qui ne sont plus sûrs non plus.
Par contre, le cipher 3DES est obsolète, il faut le bannir !


Ah oui, c'est vrai, le dossier est caché.
J'ai tellement l'habitude de l'utiliser que j'en ai oublié de dire qu'il est caché...


Sinon, pour rendre exécutable le truc, je l'ai déjà dit.
Ca dépend des OS. Avec un OS il n'y a rien à faire, sinon avec un autre, il faut rendre exécutable.

Regarde, tu verras que ça y est :

Vous devriez obtenir l'aide de acme.sh à l'écran.
Sinon, si l'exécution du script refuse de se lancer, entrez ce qui suit et retentez :
Code
chmod +x .acme.sh

Je vais ajouter de suite cette histoire de dossier caché.

[maximus23]

Sinon, pour rendre exécutable le truc, je l'ai déjà dit.Ca dépend des OS. Avec un OS il n'y a rien à faire, sinon avec un autre, il faut rendre exécutable.

Mets le par défaut même si ils le font deux fois rien de grave au moins on sera certain que c'est correct.

Tu peux effacer les commentaires pour laisser ton tuto propre pas de soucis

Fais attention, tu ne devrais plus autoriser TLSv1, ce protocole n'est plus jugé comme sûr.Enfin, c'est toi qui voit.Pareil pour les ciphers, il faut désactiver les ciphers avec échange de clés s'appuyant sur RSA, c'est des ciphers qui ne sont plus sûrs non plus.Par contre, le cipher 3DES est obsolète, il faut le bannir !

Oui c'est pour cela que je demandais ta ligne de cyphers

[alex]

Tu peux effacer les commentaires pour laisser ton tuto propre pas de soucis

Meuh non, c'est bon, ça concerne acme.sh

Par contre, relis mon post juste au dessus, j'ai édité pour dire ce qui ne va pas avec ton site test.

[maximus23]

Par contre, relis mon post juste au dessus, j'ai édité pour dire ce qui ne va pas avec ton site test.

Ok je vais regarder cela tout a l'heure et mettre mes autres domaines en wilcard aussi.

Il faut 15 minutes pour que les dns soient pris en compte entre Cloudfare et Gandi cela va très vite enfin pour moi

Puis comme je dois remettre un wampServer sur un autre PC je testerai ta méthode pour Windows

[alex]

Ca y est, tuto mis à jour.

15 minutes ? Tout ça ?!
La vache, moi je trouve ça long.
Lets Encrypt interroge directement le DNS du domaine, le DNS autoritaire, ça devrait donc être plus rapide.


Sinon, pour ta config SSL, je te conseille ceci :

Code

SSLEngine on
SSLProtocol All -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:CHACHA20-POLY1305-SHA256:!RSA:!RC4:!RC2:!CAMELLIA:!3DES:!DES:!IDEA:!SEED:!MD5:!aNULL:!eNULL:!EXP:!DHE
SSLHonorCipherOrder on

Après, tu fais ce que tu veux. Si tu veux utiliser TLSv1, libre à toi.


Attention avec Windows, tu vas être obligé d'utiliser Cygwin. Mais tu verras, ça marche bien.

[maximus23]

15 minutes ? Tout ça ?!La vache, moi je trouve ça long.Lets Encrypt interroge directement le DNS du domaine, le DNS autoritaire, ça devrait donc être plus rapide.

Pour la propagation normale c'est rapide.

Pour la propagation des txt pour les clés 30 secondes mais je laisse les 2 minutes.

Merci pour les cyphers là je dois y aller je regarde cela ce soir.

Celui qui s'y perd dans le tuto il lui faudra une superbe paire de lunettes 

Enfin pour moi super et merci quel gain de temps

[alex]

Pour la propagation normale c'est rapide.

Pour la propagation des txt pour les clés 30 secondes mais je laisse les 2 minutes.

Ah oui, d'accord ! Tu parles de la propag "normale".
Sinon oui, pour les enregistrements TXT c'est très rapide. C'est même immédiat.
Mois non plus je ne touche jamais aux 2 minutes, y a pas le feu.

Merci pour les cyphers là je dois y aller je regarde cela ce soir.

Celui qui s'y perd dans le tuto il lui faudra une superbe paire de lunettes 

Enfin pour moi super et merci quel gain de temps

Merci, c'est gentil.

[maximus23]

Voilà mes domaines sont faits pour le serveur vds

J'ai du faire quelques modifications sur les dns de Cloudfare pour un domaine car il n'a pas reconnu mes entrées type A donc j'ai du refaire manuellement mais rien de bien grave.

Bon une chose importante pour les novices il faut redémarrer apache après la mise en place des certificats.

J'ai modifié mes cyphers mais là il doit encore avoir moyen d'améliorer cela.

[alex]

J'ai du faire quelques modifications sur les dns de Cloudfare pour un domaine car il n'a pas reconnu mes entrées type A donc j'ai du refaire manuellement mais rien de bien grave.

Fais très attention avec CloudFlare, il faut que tes enregistrements A ne passent pas par le proxy CloudFlare.
Si tu as ce nuage sur les enregistrements, c'est pas bon :
Il faut que le nuage soit comme ça :



Sinon, oui, bien entendu, il faut recharger Apache quand on modifie sa configuration, donc quand on installe un certificat SSL.
De toute façon, je vais faire un tuto Apache pour avoir une config SSL solide. C'est pour bientôt.
Si j'ai 5 minutes, je ferai aussi le tuto pour Postfix et Dovecot.


Autrement, ta config va bien. Il n'y a pas de faiblesses ou vulnérabilités SSL.
Bon, moi, je suis beaucoup plus parano et donc beaucoup plus strict. Mais ta config est bonne.
Si j'étais toi, je créerais une clé Diffie-Hellman en prévision du tuto SSL Apache qui sera bientôt là.

C'est simple avec openssl :

Code

openssl dhparam -out dh-4096.key 4096

Attention, c'est long, très long !
Même une machine puissante mettra un certain temps à générer une clé Diffie-Hellman.

Sinon tout va bien en attendant, ta config est bonne.
Tu as choisi de supporter les protocoles TLSv1 et TLSv1.1, mais bon, c'est toi qui voit...

[maximus23]

Fais très attention avec CloudFlare, il faut que tes enregistrements A ne passent pas par le proxy CloudFlare.

Oui cela je le sais pas de soucis mais si tes DNS sont mauvais cela ne fonctionnera pas.

Tu as choisi de supporter les protocoles TLSv1 et TLSv1.1, mais bon, c'est toi qui voit...

Pour le V1 il y a une vulnérabilité mais c'est assez mitigé quoique les vieux navigateurs je crois qu'il faut laisser tomber tant pis.

Il faudrait peut-être mettre le V3 en plus non ?