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

[.Shad.]

Sans connaître la variable en question, je pense que c'est comme trust-server, etc... Ça veut probablement dire que tu désactives la vérification du certificat. En local ça ne représente aucun danger, mais aucun intérêt de déployer en HTTPS du coup car le chiffrage n'est pas actif.

[Diplo95]

il y a 1 minute, .Shad. a dit :

Sans connaître la variable en question, je pense que c'est comme trust-server, etc... Ça veut probablement dire que tu désactives la vérification du certificat. En local ça ne représente aucun danger, mais aucun intérêt de déployer en HTTPS du coup car le chiffrage n'est pas actif.

Si je comprends ce que tu veux dire, ça serait une option pour déployer un certificat en demandant à ce qu'on n'en tienne pas compte ?

[oracle7]

@Diplo95

Bonjour,

Merci pour le lien. @.Shad. a raison et on retrouve plus ou moins cela dans les échanges du lien (si j'ai j'ai bien compris mais je peux me tromper).

Dans tous les cas, je pense que tu ne devrais pas utiliser cette variable. Cela ne me paraît pas être un fonctionnement normal. Je crains que tu n'es en plus plus tard des problèmes lors du renouvellement du certificat. Maintenant c'est toi qui voit ...

De plus, si j'étais toi, je reverrais complétement la composition de mon identifiant et MdP de connexion. L'un des deux ou voire même les deux sont les fautifs. Je pense que tu utilises forcément des caractères spéciaux dans leur composition. Le message d'erreur est parfaitement clair sur ce point.

Eventuellement, essaies dans la déclaration de variables de mettre des simples cotes au lieu des guillets pour encadrer les valeurs d'identifiant et de mot de passe. Cela pourrait peut-être suffire à "échapper" les caractères fautifs. Mais sans garantie que cela marche !

Cordialement

oracle7😉

[Diplo95]

@oracle7

J'ai résolu le problème de connexion au NAS : il venait de la variable SYNO_DID (j'avais rajouté les xxxx).

Mais ensuite j'ai eu un autre problème, me retournant le code erreur 18 : voir le poste plus haut.

Je viens de chercher un peu plus et j'ai trouvé plus d'éléments. Dans le Wiki du code Acme.sh, partie Synology (https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide), il est dit ceci :

Citation

Et effectivement, j'ai l'option HTTP/2 activée. Ça peut aussi expliquer les erreurs lorsque le déploiement se fait en https (alors il faut passer le paramètre --insecure). MAIS : je l'ai déployé en http, donc ça ne correspond pas tout à fait à mon problème.

Si l'on fouille un peu la doc sur les paramètres d'Acme.sh (https://github.com/acmesh-official/acme.sh/wiki/Options-and-Params), on trouve ça :

--insecure         Do not check the server certificate, in some devices, the api server's certificate may not be trusted.

Donc j'avoue que je suis un peu perdu. Cependant, mon certificat est maintenant visible dans mon DSM. Il faudra que j'essaie de le renouveler et que je fasse des tests de connexion en dehors de mon réseau local, ce que je n'ai pas eu le temps de faire jusqu'à présent.

[oracle7]

@Diplo95

Bonjour,

Je soupçonne que tu t'obstines à vouloir passer en HTTPS par le port 5001. Je le répète, cela ne sert à rien puisque tu es sur ton réseau local. Ou alors tu as des pirates en herbes qui l'on investit ???

Non, il faut passer tout simplement en HTTP port 5000 et localhost comme décrit dans le TUTO.

Enfin ton identifiant/MdP tu n'en parles pas, les as-tu repris/corrigés ? Car sauf erreur de ma part, le message d'erreur initial les mettaient bien en cause, non ? avec tous les effets de bord que cela peut engendrer.

Cordialement

oracle7😉

[Diplo95]

@oracle7

non, non : regarde mon post ici

je n'ai plus de problème d'identifiant. Je suis en HTTP, mes login et mdp sont corrects.

J'ai rencontré un nouveau problème avec un code erreur 18. Une recherche m'a renvoyé sur le github du programme ou j'ai trouvé mention de la variable HTTPS_Insecure.
 

[oracle7]

@Diplo95

Bonjour,

Désolé mais là je sèche. Je n'ai jamais rencontré ce type d'erreur. Sûrement un effet de bord dû à autre chose. Mais quoi ?

Cordialement

oracle7😉

[TuringFan]

Bonjour à tous,

De mon côté la méthode fonctionne très bien mais j'ai systématiquement un problème de DID qui me force à le mettre à jour puis à forcer l’exécution du script python3.

Auriez-vous résolu ce problème ?

Bonee soirée,

[oracle7]

@TuringFan

Bonjour,

Qu'est-ce que tu entends par "le mettre à jour", que fais-tu systématiquement ?

Cordialement

oracle7😉

[TuringFan]

Pardon @oracle7 je n'étais pas clair, voici ce que je fais :

1. A chaque fois je me rends compte que mon certificat a expiré
2. Je vais donc voir ce qui cloche sur le script en le forçant avec un "-f"
3. Je constate ensuite toujours la même chose : un "check your username and password" dans les logs du script
4. Je vais alors voir le fichier de config dans "/volume1/Certs/ndd.tld/ndd.tld.conf" et je constate alors que le DID est différent de celui que j'ai en checkant via Cookie Quick Manager
5. Je fais donc la modification dans le fichier de configuration avec le nouveau DID et relance le script en "-f" et là ca fonctionne nickel !

[oracle7]

@TuringFan

Bonjour,

Effectivement, le DID varie très souvent, c'est aussi un constat que j'ai fait. C'est notamment le cas à chaque mise à jour de FireFox où il faut aller modifier la date d'expiration qui a été réinitialisée à 1 mois et ensuite aller vérifier les fichiers account.conf et ndd.tld.conf.. C'est assez contraignant je te l'accorde mais on a pas le choix.

Sinon nonobstant cela, comme tu le dis cela marche nickel.

Cordialement

oracle7😉

 

[Mic13710]

Il y a 4 heures, oracle7 a dit :

mais on a pas le choix.

Bien sur qu'il y a le choix : celui d'utiliser un compte admin restreint et sans double authentification dédié à cette seule fonction.

[Diplo95]

Bonjour,

je reviens pour poser deux questions.

1. J'ai déployé le certificat LE en passant le paramètre HTTPS_INSECURE=1. J'entends parfaitement vos doutes sur la chose, ne sachant pas réellement quelles en étaient les conséquences. Cependant, après avoir réussi à paramétrer mon reverse proxy, j'ai l'impression que tout fonctionne comme je le souhaite. Mes sites sont en https et protégés par mon certificat LE :

Est-ce qu'il y aurait une raison de s'inquiéter tout de même d'une faille qq part ?

 

2. J'aimerais faire quelques tests de déploiements de certificats pour trouver la cause de l'erreur Curl 18. (je rappelle que j'avais trouvé une solution en passant le paramètre HTTPS_INSECURE à 1). Seulement je ne voudrais pas refaire des opérations non nécessaires. Est-ce qu'il suffit que je supprime le certificat LE dans le DSM ou bien faut-il que je le supprime aussi chez OVH ?

 

Merci

Modifié le 11 avril 2021 par Diplo95

[oracle7]

@Diplo95

Bonjour,

1. il y a 21 minutes, Diplo95 a dit :

   Est-ce qu'il y aurait une raison de s'inquiéter tout de même d'une faille qq part ?

   
   A priori comme cela ne je crois pas, mais je maintient que l'usage de cette variable n'est pas "normal". Il suffit de regarder sur Github la description du processus acme.sh, sauf erreur de ma part je ne me souviens pas qu'il en soit fait état.
    

2. il y a 21 minutes, Diplo95 a dit :

   Est-ce qu'il suffit que je supprime le certificat LE dans le DSM ou bien faut-il que je le supprime aussi chez OVH ?

   Le supprimer dans DSM devrait suffire mais il te faut aussi alors bien nettoyer les répertoires acme et Volume1/Cert si tu décides de reprendre le processus à zéro.
             Nota : Tes clés OVH seront elles toujours valables (pour le domaine pour le quel elles ont été définies s'entend).
   Enfin dans ce cas, saches qu'avec LE tu n'as droit qu'à 5 cartouches par semaine pour créer, renouveler un certificat pour un même domaine.tld. A La 6ème tentative tu sera bloqué pour une semaine calendaire avant de pouvoir recommencer. Tu es prévenu !

@Mic13710

Bonjour,

OUI c'est une possibilité, mais est-elle vraiment aussi sécure que la 2FA ?

Cordialement

oracle7😉

 

[Mic13710]

il y a 15 minutes, oracle7 a dit :

OUI c'est une possibilité, mais est-elle vraiment aussi sécure que la 2FA ?

Avec un nom d'administrateur totalement incompréhensible du genre sqjfqpsoievf, un mdp long comme le bras zoifjnspvnqzpoefjqscnwlmcqoééçéà'é&à'65+8+74w<scdnqkdojcwc,wlcn, un accès limité aux fonctions minimales, doublé d'un pare feu qui bloque les tentatives non sollicitées, je ne vois aucun problème.

Il ne faut pas oublier que ce compte n'est accédé qu'en local et uniquement pour renouveler le certificat.

Après on peut tout à fait choisir de se battre avec le DID. Moi j'ai d’emblée opté pour le compte dédié.

[Diplo95]

@oracle7

Je souhaite faire des tests de déploiement uniquement. En effet, c'est lors de cette phase que j'ai un message d'erreur. SI je comprends bien, il me suffit donc bien de supprimer le certificat LE dans DSM et de refaire un déploiement.

 

il y a 29 minutes, oracle7 a dit :

A priori comme cela ne je crois pas, mais je maintient que l'usage de cette variable n'est pas "normal". Il suffit de regarder sur Github la description du processus acme.sh, sauf erreur de ma part je ne me souviens pas qu'il en soit fait état.

J'ai un peu fouillé le github et cette variable permet de remplacer l'inscription de l'argument --insecure lors du déploiement. (Ici)

Les auteurs précisent que cet argument est nécessaire lorsqu'on passe en https car Curl génère une erreur :

Citation

When we want to use https to deploy the new certificate and connect to "localhost", we need to add the --insecure option to the deploy command to prevent curl errors. refer to [https://github.com/acmesh-official/acme.sh/wiki/Options-and-Params]. If you enabled HTTP/2 you still receive a curl 16 error probably due to missing http2 dependencies on the NAS but the script succeeds.

Alors pour mon cas, je ne passais pas en https mais en http, cependant, je pense que j'avais l'option HTTP/2 choisie. C'est la raison pour laquelle je souhaite refaire un test de déploiement en jouant sur ce paramètre, histoire de comprendre d'où vient mon erreur.

[oracle7]

 @Diplo95

Bonjour,

il y a une heure, Diplo95 a dit :

SI je comprends bien, il me suffit donc bien de supprimer le certificat LE dans DSM et de refaire un déploiement.

Oui mais veilles à bien exporter auparavant toutes les variables depuis de début.

il y a une heure, Diplo95 a dit :

J'ai un peu fouillé le github et cette variable permet de remplacer l'inscription de l'argument --insecure lors du déploiement. (Ici)

C'est bien ce que je pensais, la variable en question HTTPS_INSECURE n'est en aucun citée dans le lien que tu donnes. On y parle pas de la même chose.

Par ailleurs, je ne pense pas que l'option HTTP/2 y soit non plus pour quelque chose car chez moi elle était déjà activée bien avant que je fasse mon premier certificat LE et je n'ai jamais eut besoin d'ajouter l'option --insecure à ma commande de déploiement toujours effectuée en http / 5000 / localhost.

De plus, en HTTPS avec HTTP/2 cochée si tu ne mets pas l'option --insecure dans la commande de déploiement, tu récupères une erreur 16 par curl. Donc rien avoir avec l'erreur 18  de curl figurant dans ta copie d'écran de ton post ci-dessus à 15h06 ( et objet de l'échange que tu as eut sur Github) qui elle concerne un "transfer closed with outstanding read data remaining". Donc un problème dans les échanges avec le serveur. Ne m'en demande pas plus sur l'origine ...

Non, ton erreur vient sûrement d'autre chose, je me demande si c'était pas un effet de bord lorsque tu renseignais mal le variable SYNO_DID mais je peux me tromper.

Cordialement

oracle7😉

 

 

 

Modifié le 11 avril 2021 par oracle7

[Diplo95]

@oracle7

j'espère que je ne finis pas par être lourd avec mes questions. Ce n'est pas une volonté d'imposer mes idées, mais vraiment de comprendre les choses.

J'ai regardé le code du fichier acme.sh. Voici ce qui est indiqué à la ligne 1826 :

if [ "$HTTPS_INSECURE" ]; then
      _CURL="$_CURL --insecure  "

Je n'ai que des notions de programmations, mais je pense comprendre que donner la valeur 1 à HTTPS_INSECURE équivaut à passer --insecure en argument. (d'ailleurs, je pense qu'on pourrait donner n'importe quelle valeur à HTTPS_INSECURE et ce serait le même résultat)

En ligne 1872, on a ça :

if [ "$HTTPS_INSECURE" ]; then
      _WGET="$_WGET --no-check-certificate "

En cherchant la signification, je l'ai trouvé ici :

https://explainshell.com/explain?cmd=wget+--no-check-certificate

Il y a un passage qui me met la puce à l'oreille :

Citation

As of Wget 1.10, the default is to verify the server's certificate against the recognized certificate
    authorities, breaking the SSL handshake and aborting the download if the verification fails.
    Although this provides more secure downloads, it does break interoperability with some sites that
    worked with previous Wget versions, particularly those using self-signed, expired, or otherwise
    invalid certificates.  This option forces an "insecure" mode of operation that turns the certificate
    verification errors into warnings and allows you to proceed.

Est-ce que l'erreur ne viendrait pas du fait que lorsque j'ai essayé de déployer mon certificat, mon Syno n'avait qu'un certificat, celui de synology auto-signé ?

 

Après je te rejoins sur le fait que ma situation n'est pas identique au cas présenté dans le Wiki d'Acme.sh. Je vais continuer à chercher car j'ai peur d'avoir la même erreur lors du renouvellement du certificat.

Modifié le 11 avril 2021 par Diplo95

[oracle7]

@Diplo95

Bonjour,

Waouh ! Bravo pour l'approfondissement. Du coup on en revient à ce que disait @.Shad. quand il parlait de désactivation de la vérification du certificat.

il y a une heure, Diplo95 a dit :

Est-ce que l'erreur ne viendrait pas du fait que lorsque j'ai essayé de déployer mon certificat, mon Syno n'avait qu'un certificat, celui de synology auto-signé ?

Je ne pense pas car sinon, d'autres avant toi aurait signalé ce type d'erreur ce qui n'a pas été le cas à ce jour.

Maintenant, je crois que tu as du raté un truc à un moment donné qui a conduit à récupérer cette erreur. L'usage de la variable HTTPS_INSECURE aura été un palliatif mais je le répète tu n'aurais pas dû avoir à le faire normalement.

Enfin quoi qu'il en soit, ton certificat a bien été généré et du moment que tes variables sont bien renseignées dans les fichiers account.conf et ndd.tld.conf et surtout que le DID est bien à jour et pas périmé, le renouvellement devrait ensuite se faire sans problème.

Cordialement

oracle7😉

 

[TuringFan]

Le 11/04/2021 à 19:46, Mic13710 a dit :

Avec un nom d'administrateur totalement incompréhensible du genre sqjfqpsoievf, un mdp long comme le bras zoifjnspvnqzpoefjqscnwlmcqoééçéà'é&à'65+8+74w<scdnqkdojcwc,wlcn, un accès limité aux fonctions minimales, doublé d'un pare feu qui bloque les tentatives non sollicitées, je ne vois aucun problème.

Il ne faut pas oublier que ce compte n'est accédé qu'en local et uniquement pour renouveler le certificat.

Après on peut tout à fait choisir de se battre avec le DID. Moi j'ai d’emblée opté pour le compte dédié.

Je vais regarder ça dès que j'ai un peu de temps alors

Le 11/04/2021 à 13:37, oracle7 a dit :

account.conf

Pas besoin de toucher ce fichier de mon côté

Le 11/04/2021 à 13:37, oracle7 a dit :

Sinon nonobstant cela, comme tu le dis cela marche nickel.

Complètement en ligne !
La seule amélioration que je vois et d’éventuellement un jour automatiser la diffusion du certificat au routeur.

[nebelnic]

Bonsoir,

Et bien 2eme mise à jour de certificat après un renouvellement automatique il y a 2 mois sans intervention de ma part, et ce soir échec ! Je n'ai pourtant rien touché entre temps . Je ne me souviens pas avoir mis à jour le DSM ces 2 derniers mois non plus. J'ai eu un changement de disque mais je ne vois pas en quoi cela aurait à voir...

J'ai le fichier log mais j’hésite à l'envoyer ne sachant pas le sécuriser.

Merci pour votre aide toujours précieuse.

nebelnic

[bruno78]

@nebelnic bonjour,

il serait tout de même bon de connaitre la cause de l’échec. Après, cela m'est déjà arrivé, ça peut planter un jour et passer le lendemain. Ce peut venir soit de LE, soit d'OVH, ..., des tempos ...

Si tu recherches dans le log par exemple le mot clé "error", ca te dit quoi ?

Pour sécuriser ton log, a minima, tu remplaces globalement ton domaine.tld  par "ndd.tld", ça éliminera déjà pas mal de chose . Tu peux aussi envoyer ton log par MP.

cdt, bruno78

Modifié le 14 avril 2021 par bruno78
typo

[nebelnic]

Merci  @bruno78,

Voici le fichier log modifié.

Encore merci!

nebelnic

 

 

Modifié le 14 avril 2021 par nebelnic

[.Shad.]

Tu es sûr que tu avais réglé la durée de validité de ton API sur illimité ? parce qu'il a l'air de ne plus avoir accès à la zone par l'API.

[Mic13710]

il y a une heure, bruno78 a dit :

ça peut planter un jour et passer le lendemain. Ce peut venir soit de LE, soit d'OVH, ..., des tempos ...

C'est exactement ce qui vient de m'arriver et c'est plus courant qu'on ne le pense. Echec le jour du renouvellement, réussite le lendemain. Les logs font souvent état d'erreurs de lecture des TXT, et parfois ce sont des délais de réponse trop longs. Il semblerait que les problèmes se situent de part et d'autre.