[TUTO]Création d'un Certificat "wilcard" Let'sEncrypt avec la méthode "acme.sh"

[TuringFan]

  Bonjour @oracle7,

Merci pour ce super tuto que je suis en train d'appliquer pas à pas car je ne maitrise pas du tout le SSH et que j'ai en tête sa potentielle dangerosité si mal utilisé.

Quelques questions mineures :

Le 30/05/2020 à 10:35, oracle7 a dit :

On lance l’installation d’ACME (pensez avant à remplacer dans la commande : « email@gmail.com » par votre @Mail personnelle)

• A quoi va service cette adresse email ?
• Comment peut on la changer ensuite ?

Le 30/05/2020 à 10:35, oracle7 a dit :

Cas de la double authentification

Pas super clair pour moi cette partie.

• Je comprends que cela sert à deux choses : ne pas avoir à retaper le code d'authentification à chaque fois et ne pas bloquer le déploiement du certificat. C'est bien cela ?
• Comment faire si justement on souhaite avoir à renseigner le code d’authentification systématiquement ?
• Comment faire si nous n'utilisons pour le moment pas la double authentification mais que dans le futur nous la mettons finalement en place : quels sont les manipulations coté certificat ?

Encore merci pour ce super tuto, clairement un cran au dessus de ceux que j'ai fait jusqu'à maintenant, et qui a dû demandé beaucoup de travail et de temps de préparation .

[bruno78]

Bonjour à tous, à @oracle7,

le script d'automatisation avance, mais j'ai eu assez peu de temps dispo ces derniers jours. J'ai refais des essais, l'automatisation semble bien fonctionner, mais j'ai un soucis : à savoir que le certificat que LE me crée est toujours "FAKE", donc a priori non utilisable. Et pourtant, j'ai enlevé le paramètre --staging. Mais sinon j'arrive bien à rendre le nouveau certificat opérationnel et déployé, avec tous les services pré-existants déclarés et actifs. Donc on n'est plus très loin je pense ..... .

PS : ce sera un script écrit en Python.

[.Shad.]

Du côté de @Jeff777 et moi on a un script d'automatisation en cours pour le mode DNS manuel (donc typiquement si vous hébergez votre zone publique sur votre NAS), ça marche avec le nameserver primaire mais on bloque encore sur le notify pour que le nameserver secondaire (en esclave) rafraîchisse sa zone.

[TuringFan]

Bonjour,

J'ai suivi le tuto mais j'ai une erreur lors du déploiement du certificat (méthode ajout) :
 

Unable to authenticate to localhost:5001 using https.

Savez-vous d'où cela peut venir ?

J'ai probablement un problème côté caractères spéciaux que j'utilise pour mon login et/ou mdp.

@oracle7 mentionne en effet le fait "d'échapper des caractères spéciaux" mais je ne comprends pas ce que cela veut dire.

Quelqu’un pourrait il m'aider svp ?

Merci d'avance,

Modifié le 14 juin 2020 par TuringFan

[oracle7]

@bruno78

Bonjour,

Merci de ce premier retour qui est très encourageant.

il y a 16 minutes, bruno78 a dit :

ce sera un script écrit en Python.

Cela ne m'étonne qu'à moitié que tu ai fait ce choix, une de mes connaissance m'en avait parlé et pour lui c'était le meilleur moyen d'attaquer un parseur JSON pour manipuler le fichier INFO.

Bon courage à toi pour la suite ... 😉

@TuringFan

Bonjour,

Il y a 5 heures, TuringFan a dit :

• A quoi va service cette adresse email ?
• Comment peut on la changer ensuite ?

• a priori (du moins de ce que j'ai pu en comprendre) c'est utilisé pour de l'authentification dans le processus.
• l'@MAIL quant à elle, comme elle apparaît dans le fichier "account.conf" lui même situé dans "/usr/local/share/acme.sh", devrait pouvoir être modifié/remplacée si besoin (dans le futur comme tu dis).

Il y a 5 heures, TuringFan a dit :

Je comprends que cela sert à deux choses : ne pas avoir à retaper le code d'authentification à chaque fois et ne pas bloquer le déploiement du certificat. C'est bien cela ?

Oui en quelque sorte. Lors du déploiement, le script déroule une procédure de connexion au NAS ce qui déclenche automatiquement le processus de double authentification qui lui, renverait une interface à l'utilisateur pour saisir son code à 6 chiffres. C'est donc en positionnant la variable d'environnement "SYNO_DID" avec la bonne valeur, on "courcircuite" ce processus d'affichage en transmettant directement les éléments nécessaires d'authentification au NAS. Ainsi le déploiement devient "transparent" pour l'utilisateur.

Il y a 5 heures, TuringFan a dit :

Comment faire si justement on souhaite avoir à renseigner le code d’authentification systématiquement ?

Tu installes la double authentification tout simplement et une bonne fois pour toute. Comme cela tu es toujours sécurisé au moins pour la connexion au NAS.

Il y a 5 heures, TuringFan a dit :

Comment faire si nous n'utilisons pour le moment pas la double authentification mais que dans le futur nous la mettons finalement en place : quels sont les manipulations coté certificat ?

Je ne sais te répondre par rapport au certificat. mais pourquoi attendre, mets là en place maintenant et plus de prise de tête à se faire, non ?

Cordialement

oracle7😉

[oracle7]

@TuringFan

Ta question est arrivée pendant que je rédigeais ma précédente réponse.

il y a 4 minutes, TuringFan a dit :

J'ai probablement un problème côté caractères spéciaux que j'utilise pour mon login et/ou mdp.

@oracle7 mentionne en effet le fait "d'échapper des caractères spéciaux" mais je ne comprends pas ce que cela veut dire.

Oui il y a de grandes chances que ce soient des caractères dits spéciaux qui gênent le processus. Saches que l'on peut faire des mots de passes tout aussi forts sans avoir recours à ces caractères. Je ne sais plus si c'est @Fenrir ou @unPixel qui expliquaient cela dans un de leurs tutos.

Donc, normalement et justement dans la syntaxe Shell script, l'usage des "simples cote" (ou apostrophes en français) : " ' " permet de ne pas tenir compte (si je puis dire) de ces caractères spéciaux (par ex ? / \ : " * < > . ). On dit alors que l'on les "échappent" (ce qui n'est pas forcément la meilleure traduction du terme anglais "escape"). Certains processus les remplacent même automatiquement et de façon transparente par l'équivalent de leur code ASCII, par ex "%2A" pour une " * "  afin de poursuivre leur exécution sans erreurs. C'est aussi ce que l'on fait sous Windows dans les noms de fichiers.

Cordialement

oracle7😉

[TuringFan]

@oracle7,

Merci pour ton retour.

CA MARCHE mais uniquement en utilisant l'option par défaut http et port 5000, en effet mes premières tentatives étaient avec https et port 5001.

Le 30/05/2020 à 10:35, oracle7 a dit :

Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes :

Par défaut : « http » mais on peut fixer à « https »

# export SYNO_Scheme="http"

Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront.

# export SYNO_Hostname="localhost"

Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS

# export SYNO_Port="5000"

En toute honnêteté ’avais opté pour le hhtps sans vraiment comprendre l'impact mais en me disant qu'un accès en https était toujours mieux qu'un http.

En revanche peut être aucun rapport mais j'ai noté une différence avec ta console qui affiche  :

La mienne affiche la même chose sans l'avant dernière ligne : le "http.header"

Par contre j'ai bien le http not restarded

Le 30/05/2020 à 10:35, oracle7 a dit :

Nota : On peut remarquer dans le message ci-dessus la ligne : « http services were NOT restarded », ne sachant pas ce qu’il faut en faire, je l’ai provisoirement ignorée. Je n’ai d’ailleurs pas constaté par la suite de disfonctionnements qui lui soient liés.

Cela dit, je compte sur les « initiés » pour me dire s’il y a une quelconque action à exécuter vis-à-vis de ce message. D’avance merci, je mettrai à jour la présente procédure en conséquence.

En espérant que mes remarques pourront également aider si certains ont les mêmes problèmes

Merci encore @oracle7

à l’instant, oracle7 a dit :

Donc, normalement et justement dans la syntaxe Shell script, l'usage des "simples cote" (ou apostrophes en français) : " ' " permet de ne pas tenir compte (si je puis dire) de ces caractères spéciaux (par ex ? / \ : " * < > . ). On dit alors que l'on les "échappent" (ce qui n'est pas forcément la meilleure traduction du terme anglais "escape"). Certains processus les remplacent même automatiquement et de façon transparente par l'équivalent de leur code ASCII, par ex "%2A" pour une " * "  afin de poursuivre leur exécution sans erreurs. C'est aussi ce que l'on fait sous Windows dans les noms de fichiers.

Très clair, merci.

[oracle7]

@.Shad. et @Jeff777

Pour votre info si besoin en est, @unPixel et @PPJP avaient décrit ce processus d'automatisation dans les 12 ou 13 pages du Tuto de @unPixel au travers d'un script qui a priori est obsolète maintenant mais dont on doit pouvoir s'inspirer et remettre au gout du jour.

Cordialement

oracle7😉

[TuringFan]

@oracle7,

Je viens d'essayer d'exporter le certificat depuis le NAS vers le RT et visiblement j'ai un problème de mon côté.

 

As tu la même chose ? Sais tu comment gérer ce problème ?

[oracle7]

@TuringFan

J'ai eut aussi ce soucis.

Il ne faut pas exporter ton certificat depuis le NAS. Ne pas utiliser non plus de fichiers ".pem". C'est bizarre mais cela ne marche pas ! Tu dû voir ...

Tu copies les fichiers qui ont générés dans "Volume1\Certs\ndd.tld" sur ton PC/Mac.

Sur le RT tu importes directement cette copie ( ndd.tld.key, ndd.tld.cer et l'intermédiaire ca.cer).

Cordialement

oracle7😉

[TuringFan]

@oracle7,

Ok merci.

Question très très très bête (mais pour le moment je ne fais que de la configuration sans mettre de données sur mon NAS) comment je fais pour récupérer les fichiers de Volume1\Certs\ndd.tld : où est l'explorateur de fichier ?

Cordialement,

[oracle7]

@TuringFan

il y a 18 minutes, TuringFan a dit :

comment je fais pour récupérer les fichiers de Volume1\Certs\ndd.tld : où est l'explorateur de fichier ?

Là il te faut utiliser "WinSCP" sous Windows (je ne lui connais pas d'équivalent sur Mac, désolé). C'est en tous cas, le plus facile à mettre en œuvre car il a une interface graphique contrairement à PuTTY. Je te laisse le découvrir. Rien de compliqué rassures toi.

Cordialement

oracle7😉

[.Shad.]

Il y a 2 heures, oracle7 a dit :

@.Shad. et @Jeff777

Pour votre info si besoin en est, @unPixel et @PPJP avaient décrit ce processus d'automatisation dans les 12 ou 13 pages du Tuto de @unPixel au travers d'un script qui a priori est obsolète maintenant mais dont on doit pouvoir s'inspirer et remettre au gout du jour.

Cordialement

oracle7😉

Leur tutoriel n'est pas obsolète car il englobe en plus le redémarrage des paquets après l'installation du nouveau certificat. 😉

Ce sur quoi je bosse couvre le mode DNS manuel (je te laisse regarder sur le github de acme.sh), donc sans passer par une api pré-configurée.
La vraie bonne méthode est de créer sa propre API pour son serveur DNS, si on héberge notre zone nous-même, ou d'utiliser le DNS alias mode si on a un 2ème nom de domaine avec une API.

Mais la première est hors de ma portée, la seconde n'est pas applicable à tous.

[TuringFan]

il y a une heure, oracle7 a dit :

@TuringFan

Là il te faut utiliser "WinSCP" sous Windows (je ne lui connais pas d'équivalent sur Mac, désolé). C'est en tous cas, le plus facile à mettre en œuvre car il a une interface graphique contrairement à PuTTY. Je te laisse le découvrir. Rien de compliqué rassures toi.

Cordialement

oracle7😉

Au top ! Merci (encore) !

Pour info ça a fonctionné en important uniquement clef et certificat mais en laissant kle champs certificat intermédiaire vide.

[oracle7]

@.Shad.

Bonjour,

Tu as sans doute lu un peu trop rapidement ma précédente réponse, aussi je ferai juste une petite mise au point :

Il y a 13 heures, .Shad. a dit :

Leur tutoriel n'est pas obsolète

Je tiens à préciser que ne n'ai jamais laisser entendre que leur tutoriel était obsolète, je ne me permettrais pas. Je parlais seulement du script d'automatisation qu'ils avaient produit et me basant sur les propos explicites de @PPJP lui même , je le cite pour mémoire :

Le 29/04/2020 à 12:40, PPJP a dit :

Ce script n'est sans doute plus fonctionnel car il y a eu des modifications du DSM au niveau des certificats (et peut-être coté acme)

 

Il y a 13 heures, .Shad. a dit :

La vraie bonne méthode est de créer sa propre API pour son serveur DNS, si on héberge notre zone nous-même

Là on est bien d'accord, c'est aussi ce que j'avais dis à @Jeff777 dans une réponse en date du 31/05/2020 dernier.

Le 31/05/2020 à 12:44, oracle7 a dit :

@Jeff777

Le 31/05/2020 à 12:36, Jeff777 a dit :

Pour le certificat wildcard SSL for free je saisis les enregistrements TXT dans ma zone publique de DNS Serveur sur le NAS (ns.mondomaine.ovh)

Il n'y a peut-être pas de solution avec OVH vu que je n'ai pas de zone OVH.

Effectivement, à moins de développer ta propre API à l'image de celle d'OVH (mais là il y a du boulot !) je ne vois pas de solution dans ton cas. Désolé de t'avoir donné de faux espoirs avec ma méthode.

Cordialement

oracle7😉

[.Shad.]

Il y a du boulot mais pas tant que ça je pense pour un initié ^^

Reste à le trouver !

[oracle7]

@.Shad.

A mon humble avis, ce n'est pas ce qui manque ici, il faut juste qu'un d'entre eux accepte d'y consacrer un peu de son précieux temps 😏

Cordialement

oracle7😉

[zerda]

Je viens de suivre le tuto et tout fonctionne nickel !! Merci à l'auteur d'avoir compilé toutes les infos pour en faire un tuto sympa et clair 

[TuringFan]

Le 14/06/2020 à 20:38, oracle7 a dit :

@TuringFan

J'ai eut aussi ce soucis.

Il ne faut pas exporter ton certificat depuis le NAS. Ne pas utiliser non plus de fichiers ".pem". C'est bizarre mais cela ne marche pas ! Tu dû voir ...

Tu copies les fichiers qui ont générés dans "Volume1\Certs\ndd.tld" sur ton PC/Mac.

Sur le RT tu importes directement cette copie ( ndd.tld.key, ndd.tld.cer et l'intermédiaire ca.cer).

Cordialement

oracle7😉

Bonjour @oracle7,

J'ai finalement l'impression que cela ne fonctionne pas : j'ai toujours un certificat intermédiaire illégal !

J'ai essayé sans mettre d'intermédiaire et ça marche ... pour un temps : je me suis en effet rendu compte que mon VPN ne fonctionnait plus, en allant dans le paquet VPN Plus il y a un message d'erreur en lien avec le certificat justement.

As tu une idée ?

Cordialement,

[oracle7]

@TuringFan

Bonjour,

C'est une belle colle que tu me poses là.

J'avoue ne pas trop savoir. Pour ma part j'avais procédé comme je te l'ai indiqué précédemment en important les 3 fichiers issus de la génération. Force est de constaté que je n'ai pas rencontré les problèmes que tu évoques. Du coup je suis un peu sec pour te répondre.

A tout hasard, as-tu essayé d'arrêter proprement le RT, de le débrancher électriquement, attendre au moins une minute et de le redémarrer tout aussi proprement, histoire que tous les caches mémoire soient bien vidés. Ensuite, tu réimportes les trois fichiers du certificat . Cela ce coûte rien d'essayer et peut être que ...

Cordialement

oracle7😉

[bruno78]

Bonjour,

je reviens vers vous à propos de l'automatisation complète du processus sur DSM. ... Et là je me casse les dents .... il doit me manquer une info ...

1. j'ai fait un petit script python qui réalise les opérations suivantes :
   1. sauvegarde des fichiers INFO et DEFAULT (/usr/syno/etc/certificate/_archive)
   2. lecture des fichiers INFO et DEFAULT
   3. renouvellement du certificat (SYNO_Create = 1; /usr/local/share/acme.sh/acme.sh --cron --force --home /usr/local/share/acme.sh/) (--orce pour le forcer à renouveller le certificat puisque la date de renouvellement [T0+60j par defaut] n'est pas atteinte.
   4. lecture des nouveaux fichiers INFO et DEFAULT suite au renouvellement
   5. mise à jour de INFO en inscrivant les services sur le nouveau certificat par defaut
   6. renommage de la description de l'ancien certificat en "xxx_old"
2. tous les contrôles et traces prouvent que le script fonctionne.
   1. le nouveau fichier INFO est correct et contient bien la référence du nouveau certificat créé.
   2. Ce nouveau certificat est bien créé dans l'arborecence ./_archive
   3. le nouveau fichier INFO est bien déployé dans le DSM SYno (contrôle de la fenêtre Sécurité > certificat)
   4. la trace de la commande acme.sh montre que c'est OK
   5. la date d'expiration du nouveau certificat est bien à T0+90j, la date de renouvellement à T0+60j
   6. les fichiers LetsEncrypt mis à jour dans /volume1/Certs sont cohérents avec ce nouveau certificat généré.
3. malgré cela, un test sur un domaine xxx.domain.tld qui a donc été renouvelé montre que le certificat utilisé est toujours l'ancien ! (qui pourtant est vierge de services)
4. le supprime l'ancien certificat via le DSM : idem
5. je redémarre nginx : idem

Donc je ne comprends pas comment le site peut utiliser un certificat qui n'existe plus sur le DSM ! (et oui, je nettoie le cache des navigateurs à chaque essai)

Donc si une bonne âme avait des pistes de réflexions, je suis preneur .... Il doit surement rester une référence à l'ancien certificat quelque part ? mais même dans ce cas là, puisqu'il a été supprimé, il ne devrait pas pouvoir être utilisé ?

Merci

[Jeff777]

bonjour @bruno78

Si je comprends bien, la méthode de @oracle7 s'arrête à l'association des services avec le nouveau certificat. Et là tu essaies une méthode pour faire la dernière étape. C'est cela ?

[bruno78]

@Jeff777,

oui c'est exactement cela. Et ayant mené le process quasiment jusqu'au bout, je ne comprends pas que le navigateur me dise utiliser un certificat que j'ai supprimé du NAS .... Il doit y avoir un flag quelque part ....??

[oracle7]

@bruno78

Bonjour,

Je viens de re balayer le Tuto de UnPixel, aux pages 6-7 il évoque bien le même problème de non prise en compte du certificat que tu cites. Mais il n'indique pas vraiment de solution palliative. En plus ce n'est pas clair car ensuite il dit que le problème est réglé mais rien de plus.

Par ailleurs, quand on observe le contenu du répertoire "/usr/syno/etc/certificate" on y trouve aussi un répertoire "system/default" qui contient les fichiers du certificat mais au format ".pem". Finalement je me demande s'il n'y aurait pas un lien entre ces fichiers et le problème que tu évoques. De plus je ne saurais dire à quoi correspondent ces fichiers ".pem" vu qu'ils sont cryptés : l'ancien ou le nouveau certificat par défaut ?

Une autre piste à regarder : il semblerait que les fichiers du certificat soient aussi dupliqués dans tous les répertoires inclus dans le répertoire ""/usr/syno/etc/certificate/ReverseProxy". Du coup en plus de modifier les fichiers INFO et DEFAULT, ne faudrait-il pas faire une conversion des fichiers du certificat (".key', ".cert", etc ...) en ".pem" et les recopiier par remplacement dans chacun des dossiers du répertoire "ReverseProxy" suscité ? Ton avis STP ?

Cordialement

oracle7😀

Modifié le 21 juin 2020 par oracle7

[bruno78]

@oracle7, @Jeff777,

du coup, je viens via le DSM de basculer le service en cause sur un autre certificat puis de le ramener sur celui par défaut que j'avais renouveler, .... et là c'est bon, le certificat renouvelé est bien pris en compte ! Mais je ne trouve dans les arborescences /volume1/Certs ou /usr/syno/etc/certificate aucun fichier ayant été modifié suite à cette modif (à part bien sûr le fichier INFO puisque le service a été bougé de certificat). Mais au final le fichier INFO est bien le même qu'avant cet aller-retour !

En particulier, les fichiers .pem inclus dans system/default n'ont pas bougé.

Existe t'il une commande linux un peu globale pour voir les fichiers qui ont été modifiés dans une arborescence dans un certain laps de temps ?