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

[Pinpon_112]

@oracle7

Bonjour,

Je viens de réessayer de créer des clés et je reçois une page qui dit :

Citation

502 Bad Gateway

The server returned an invalid or incomplete response.

 

[bruno78]

@Pinpon_112 bonjour,

mais es-tu arrivé à l'écran API d'OVH ? (https://eu.api.ovh.com/createToken/), puis à te logger et entrer tes paramètres pour générer les clés ?

Bruno78

[Pinpon_112]

@bruno78

Bonjour,

Oui, je viens même de réessayer via ton lien et en créant tout comme dans le tuto et j'arrive avec la même réponse...

[oracle7]

@Pinpon_112

Bonjour,

C'est peut-être dû à une surcharge momentanée des serveur OVH. Cela arrive malheureusement assez souvent.

Ceci dit, d'une façon générale peux-tu STP être plus explicite dans la description de tes actions, cela nous faciliterait la nécessaire tâche de "décryptage" pour mieux cerner le problème. Merci d'avance.

Cordialement

oracle7😉

[Pinpon_112]

@oracle7 @bruno78

Je vais sur le lien suivant : https://eu.api.ovh.com/createToken/

Ensuite, je rempli le tout comme sur la copie d'écran.

Dans la case login, je renseigne mon login ovh, celui qui commence par ds...-ovh.  Pour le votredomaine.tld, je le remplace partout par ndd.net.

Ensuite, je clique sur créer les clés et j'arrive sur la page 502 Bad Gateway.

J'obtiens cette page depuis le début...  J'ai pu créer les clés la première fois et lorsque j'ai du recommencer la procédure, j'avais la même erreur.  Je suis donc repartis des clés créés et sauvegardées.  La situation vaut pour Chrome, Firefox et Safari.

[oracle7]

@Pinpon_112

Bonjour,

il y a 10 minutes, Pinpon_112 a dit :

Dans la case login, je renseigne mon login ovh, celui qui commence par ds...-ovh.  Pour le votredomaine.tld, je le remplace partout par ndd.net.

Même si normalement on arrive au même résultat, je préfère personnellement constituer l'URL suivante :

Citation

https://api.ovh.com/createToken/?GET=/domain/zone/votre-domaine.tld/*&POST=/domain/zone/votre-domaine.tld/*&PUT=/domain/zone/votre-domaine.tld/*&GET=/domain/zone/votre-domaine.tld&DELETE=/domain/zone/votre-domaine.tld/record/*

dans un éditeur de texte et faire les "remplacés" de "votre-domaine.tld" par "ndd.tld" dans celui-ci. Ainsi je suis sûr de la chaine que je copie ensuite dans la barre d'URL d'un navigateur. Ça c'est une chose !

Maintenant, si cela ne marche toujours pas et vu ce que tu as répondu précédemment à @bruno78, je te cites :

Le 05/10/2020 à 11:55, Pinpon_112 a dit :

Le 05/10/2020 à 11:47, bruno78 a dit :

As-tu fait plusieurs tentatives de créations de clés au départ ?

J'ai effectivement dû m'y reprendre à plusieurs fois avant d'avoir le bon certificat.  J'ai toujours repris les identifiant de l'API qui ont été créé lors de la première tentative.

Je te proposes une action "radicale" pour repartir à zéro avec tes clés OVH. On va supprimer chez OVH toutes les API que tu aurais pu créer lors de tes multiples essais. Ainsi pas de risque de confusions entre elles. OK ?

Pour cela je te demande, si tu le veux bien, de suivre les instructions suivantes :

NOTA : Sois très attentif en naviguant dans cette arborescence et vérifies bien toutes tes actions avant de valider chacune d'elles ... Regardes bien la syntaxe des liens !

1. ·         Se connecter sur OVH ici : https://api.ovh.com/console/

2. ·         Aller sur : https://api.ovh.com/console/#/me/api/application#GET (i.e. tu développes/navigues dans l'arborescence "/me/...") et cliquer sur le bouton « execute »

3. ·         On obtient la liste des ID d’applications API déjà créées

4. ·         Dans https://api.ovh.com/console/#/me/api/application/{BapplicationId}#GET saisir/coller l’ID dans le champ « applicationId » puis « execute »
   Cela te permet de voir à quoi (quel certificat) correspond l'application.

5. ·         Pour supprimer l’application : aller dans : https://api.ovh.com/console/#/me/api/application/{applicationId}#DELETE et saisir/coller l’ID dans le champ « applicationId » puis « execute ».

6.       Tu recommences au point 4 pour chaque ID figurant dans la liste du point 3.

Une fois toutes les applications supprimées, tu te déconnectes d'OVH et tu reprends le processus de créations des clés selon le TUTO et comme expliqué ci-avant.

Cordialement

oracle7😉

 

[Pinpon_112]

@oracle7

Bon, je viens de faire tout cela.

Petite parenthèse, je n'avais qu'une seule API en cours.

J'ai de nouvelles clés.  Grande question, comment les intégrer dans les certificats sans devoir tout recommencer ?

Merci pour ton aide très précieuse.

[oracle7]

@Pinpon_112

Bonjour,

Eh bien c'est parfait tout cela ! Plus de problèmes de clés. Tu les as bien sauvegardées ?

il y a 16 minutes, Pinpon_112 a dit :

Grande question, comment les intégrer dans les certificats sans devoir tout recommencer ?

Désolé mais tu n'as trop le choix dans ce cas :

• Dans une nouvelle session SSH, tu exportes toutes les variables d'environnement des points 2 (CERT_HOME, ACME_HOME) et 3.2 (OVH_xxxx) du TUTO.
• Dans DSM, il vaut mieux supprimer tous certificats wilcard créés précédemment (sauf les synology). idem pour les répertoires "ndd.tld" dans "/volume1/Certs".
• Tu reprends le TUTO au point 4, etc ...

Cordialement

oracle7😉

 

Modifié le 7 octobre 2020 par oracle7

[Pinpon_112]

@oracle7

Bon, lors du changement partiel, j'ai eu des problèmes.  J'ai donc tout supprimé via ssh ainsi que mon certificat chez OVH.

J'ai alors tout recommencé de A à Z et j'ai un nouveau certificat tout propre, tout neuf.  Plus qu'à attendre 60 jours et de voir ce qu'il se passe avec le renouvellement.

Merci pour votre aide précieuse.

[Einsteinium]

Nettoyage du topic afin de mettre fin au HS

Pour ceux qui maitrise la langue de Shakespeare, qui ont des bases et souhaitent une application plus rapide :

https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide

[TuringFan]

Le 04/10/2020 à 21:10, oracle7 a dit :

@TuringFan

Bonjour,

Dans le fichier "/volume1/Certs/ndd.tld/ndd.tld.conf" ton identifiant et ton MdP sont sauvegardés dans des variables SAVED_SYNO_Username et SAVED_SYNO_Password.

Est-ce que l'identifiant et le MdP contenu dans ces variables, sont bien ceux que tu as utilisé à savoir : "god" et "azertyuiop123" ?

On est bien d'accord que cet identifiant et le MdP sont ceux de ton administrateur du NAS ? car grâce à ces variables c'est comme si l'administrateur du NAS faisait lui même le déploiement.

Pour éviter le dernier message, modifie le Timeout de connexion et passes le à 120 sec en éditant les paramètres du site que tu utilises pour te connecter avec WinSCP :

Il me semble aussi que tu as déjà eu le problème précédemment en choisissant le couple https / 5001. Je te rappelle que le processus de création se passe sur ton réseau local donc, à moins que tu ais des prédateurs  sur ce dernier, cela ne sert à rien de faire du HTTPS en local (ni même du VPN) pour moi cela n'a pas de sens, je conçois aisément que l'on veuille verrouiller à l'extrême les choses pour les communications avec l'extérieur mais pas en local). En plus le déploiement se fait sur ton NAS soit le localhost et tu ne déploies pas sur un NAS distant que je saches.

Donc, je t'invite à n'utiliser que le couple http/5000 pour les variables.

Vérifies aussi, si tu utilises la double authentification, que le DID actuel (voir le TUTO pour le récupérer) est bien celui qui est sauvegardé dans la variable SYNO_DID ?

Indirectement c'est aussi cette éventuelle différence qui pourrait conduire au message demandant de vérifier ton identifiant et MdP.

Cordialement

oracle7😉

 

@oracle7 et @bruno78

C'est bon ça fonctionne ! Merci encore.


J'avais (i) l'horloge de mon PC qui n'était pas à l'heure et (ii) effectivement mon DID n'était plus bon (d'ailleurs je ne comprends pas pourquoi car je n'ai jamais touché à la double authentification).

J'ai également toujours un même message d'erreur (mais qui n'empeche visiblement pas la bonne application de la méthode) :



En espérant que cela sera utile à d'autres.

Dernière question : est il possible d'exporter automatiquement le certificat (après renouvellement) vers un routeur du même réseau ou d'utiliser une autre méthode type reverse proxy ou similaire pour ne plus avoir à gérer les certificat et presque pouvoir les "oublier" ?

Merci !

[oracle7]

@TuringFan

Bonjour,

Content pour toi que tu ais réussi à obtenir ton certificat par cette méthode.

il y a 22 minutes, TuringFan a dit :

J'ai également toujours un même message d'erreur (mais qui n'empeche visiblement pas la bonne application de la méthode) :

Si tu regardes bien le messages, tu verras que "acme.sh" s'y reprend à plusieurs fois pour finalement télécharger le fichier "master.tar.gz". Donc c'est bon, pas d'inquiétude à avoir.

il y a 22 minutes, TuringFan a dit :

est il possible d'exporter automatiquement le certificat (après renouvellement) vers un routeur du même réseau ou d'utiliser une autre méthode type reverse proxy ou similaire pour ne plus avoir à gérer les certificat et presque pouvoir les "oublier" ?

Pas à ma connaissance. Pour le routeur il faut copier les fichiers "ndd.tld.key", "ndd.tld.cer" et "ca.cer" depuis le répertoire "Volume1/Certs/ndd.tld/" pour ensuite les importer sur le routeur. A l'heure actuelle on n'a pas le choix de procéder autrement.

EDIT : Pour le DID, cela peut venir du fait que tu ais nettoyé les cookies de ton navigateur en effaçant les données de sites.

Cordialement

oracle7😉

Modifié le 11 octobre 2020 par oracle7

[oracle7]

@cadkey

Bonjour,

il y a une heure, cadkey a dit :

Ais-je raté l'utilité de ce tuto?

Sans être désobligeant, je crains que oui. Comme tu le dis toi-même, tu n'as effectivement pas compris l'intérêt de la méthode décrite dans ce TUTO. Je t'invites donc à bien relire tout le préambule du TUTO où j'ai essayé d'expliquer la problématique et la démarche suivie, de façon la plus détaillée possible et notamment comment on s'affranchit de l'ouverture du port 80, laquelle ne se résout pas, à mon humble avis, en installant simplement web station.

Je peux simplement te garantir que la méthode marche et sans aucune autre intervention une fois en place. Maintenant si elle ne te convient pas pour x raisons, libre à toi d'en utiliser une autre, tu n'as aucune obligation. Je ne fais ici que proposer une solution parmi d'autres pour créer et assurer le renouvellement automatique d'un certificat "wilcard" Let'sEncrypt pour un domaine personnalisé.

Cordialement

oracle7😉

[.Shad.]

Outre le port 80, le gros avantage : tu installes une nouvelle application sur ton NAS, tu mets en place un proxy inversé.

Et là problème, tu veux par exemple créer nextcloud.ndd.tld, mais il ne fait évidemment pas partie des sous-domaines pour lesquels ton certificat est valide. Du coup tu dois recréer un certificat en ajoutant ce domaine.

Avec un wildcard tous les noms possibles sont déjà validés. Tu n'as rien à faire. Gros gain de temps si tu crées souvent des nouveaux sous-domaines, et beaucoup plus facile dans tous les cas.

 

[Audio]

Le 11/10/2020 à 21:19, TuringFan a dit :

@oracle7 et @bruno78

C'est bon ça fonctionne ! Merci encore.


J'avais (i) l'horloge de mon PC qui n'était pas à l'heure et (ii) effectivement mon DID n'était plus bon (d'ailleurs je ne comprends pas pourquoi car je n'ai jamais touché à la double authentification).

J'ai également toujours un même message d'erreur (mais qui n'empeche visiblement pas la bonne application de la méthode) :



En espérant que cela sera utile à d'autres.

Dernière question : est il possible d'exporter automatiquement le certificat (après renouvellement) vers un routeur du même réseau ou d'utiliser une autre méthode type reverse proxy ou similaire pour ne plus avoir à gérer les certificat et presque pouvoir les "oublier" ?

Merci !

Bonjour,

J'ai eu les mêmes ennuis que @TuringFanpour renouveler mon certificat arrivé à moins de 60 jours de l'échéance. La version 1.44 du script Python est au poil pour les log merci @bruno78 et @oracle7.

1 - Les Application, Secret et Consumer Keys n'étaient pas sauvegardées dans le fichier account.conf: vite réparé tout était bien sauvegardé sur le PC.

2 - Il m'a fallu reprendre tout la procédure du Tuto sauf la génération des clefs DNS OVH et j'ai eu le même message d'erreur que @TuringFanlors du téléchargement du master.tar.gz. Cela n'a pas semble-t-il affecté la suite car la génération du nouveau certificat a fonctionné tout de suite.

3 - Le PWD de connexion à DSM contenait des caractères spéciaux et bien que j'avais mis des simples quote pour les escaper (comme dit dans le tuto) ça ne marchait pas, acme.sh ne parvenait pas à se connecter à la machine pour déployer le certificat: j'ai modifié le pwd (sans caractères spéciaux ce coup-ci), refait le DID car j'utilise la double authentification et le déploiement du certificat a fonctionné tout de suite! Donc éviter les caractères spéciaux dans les PWD comme souvent conseillé.

3 - Je confirme qu'il vaut mieux utiliser le schéma HTTP plutôt que le schéma HTTPS, ça n'a pas marché pour moi avec ce dernier, peut-être une mauvaise interaction avec le proxy server de DSM.  de toute manière je n'ai pas de prédateur sur mon réseau local....!

Quant à l'utilité de ce tuto, je peux confirmer à @cadkeyque c'est hyper pratique quand on a une dizaine de sous-domaines déclaré dans le DNS de son domaine et que le wilcard LE s'applique automatiquement à tous!

Merci à tous

 

[oracle7]

@Audio

Bonjour,

Merci pour ce retour positif.

Je suis juste étonné vis à vis que les clés OVH n'étaient pas sauvegardées. En principe c'est automatiquement réalisé par le script "acme.sh". Peut-être que lors de précédants essais (échoués), cela n'avait pu être fait et ensuite il saute cette phase pour aller directement lire les valeurs sauvegardées parce que pour lui, le certificat a déjà été créé ???

Toujours est-il, tu y es arrivé et c'est ce qui importe.

Cordialement

oracle7😉

[Einsteinium]

Il y a 4 heures, Audio a dit :

Je confirme qu'il vaut mieux utiliser le schéma HTTP plutôt que le schéma HTTPS, ça n'a pas marché pour moi avec ce dernier, peut-être une mauvaise interaction avec le proxy server de DSM.  de toute manière je n'ai pas de prédateur sur mon réseau local....!

Après c’est un script en localhost... donc on utilise le http... pas le https...

[.Shad.]

Exact.

[Audio]

Pour information j'ai pu exporter le certificat Wildcard LE du serveur sur lequel il a été généré et l'importer sur deux autres serveurs Synology sans problème. J'ai utilisé les procédures sur DSM, sans avoir recours à une console. Il faut juste redémarrer le serveur web ou supprimer l'ancien certificat pour que le nouveau soit pris en compte.

Le nom de ces serveurs (sousdomaine.ndd.tld) étaient déclarés sur le premier serveur dans le proxy et faisaient donc partie de la lise couverte par le certificat LE.

J'ai trouvé ça top! une seule manip de génération et 3 serveurs "servis".

[oracle7]

@Audio

Bonjour,

Juste pour mon information :

il y a 15 minutes, Audio a dit :

J'ai utilisé les procédures sur DSM, sans avoir recours à une console.

Tu peux STP préciser de quoi il retourne avec ces procédures ? Merci.

Cordialement

oracle7😉

[Audio]

il y a 1 minute, oracle7 a dit :

@Audio

Bonjour,

Juste pour mon information :

Tu peux STP préciser de quoi il retourne avec ces procédures ? Merci.

Cordialement

oracle7😉

Bonjour,

Il s'agit des commandes accessibles sur la page Panneau de configuration>Sécurité>Certificat pour manipuler les certificats.

Sur le serveur qui a servi à la génération du certificat j'ai utilisé la commande "Exporter le certificat": cela génère un zip avec les 3 fichiers .pem: cert, chain et publickey.

Sur les 2 autres serveur j'ai utilisé la commande "ajouter" et choisi l'option "Ajouter un nouveau certificat" qui permet de désigner les 3 fichiers .pem à importer.

Une fois l'importation faite, il suffit de désigner le certificat LE Wildcard comme le certificat par défaut et soit de supprimer le ou les anciens certificats ou simplement de redémarrer le serveur Web.

Cordialement

[oracle7]

@Audio

Merci de ta réponse.

En fait je connaissais la manipulation MAIS au travers de tes propos que j'ai manifestement mal traduits, j'avais imaginé que tu employais une toute autre procédure. D'où ma question, qui finalement était C....

Cordialement

oracle7😉

[Audio]

Le 15/10/2020 à 19:20, Einsteinium a dit :

Après c’est un script en localhost... donc on utilise le http... pas le https...

Merci @Einsteinium, je comprends maintenant pourquoi le HTTPS ne fonctionnait pas.

Cordialement

[Jeff777]

Bonjour @Audio,

Si tu sélectionnes "remplacer" sur la dernière image puis importer  tu n'as pas besoin de redémarrer le serveur ni de détruire l'ancien certificat. 

Soit tu n'avais qu'un certificat alors celui-ci est remplacé et est d'office par défaut, soit tu en as plusieurs, il faut alors spécifier lequel tu veux remplacer et si nécessaire cocher par défaut.

[Pinpon_112]

Petite question, les certificats importés seront-il mis à jour automatiquement comme le premier ou faudra-t-il refaire la manip tous les 3 mois ?