[TUTO] Certificat Let's Encrypt avec acme.sh & api Ovh en Docker (DSM6/7) (Update 07/09/22)

[Mic13710]

Si vos ndd fonctionnent sur le 443 (https), il est préférable de fermer le port 80. Inutile de laisse un port http ouvert aux quatre vents.

L'ensemble me parait bon, mais encore une fois, je ne peux pas dire si tout est ok. C'est uniquement vous qui pouvez le savoir en faisant des tests.

Mais vous ne répondez toujours pas à propos du blocage chez ovh !

Il y a 21 heures, domtous a dit :

il reste toujours le problème de la connexion chez OVH en mode échec.

Edit : je n'ai pas posé la question concernant le paramétrage du NAS. Avez-vous au moins suivi et appliqué le tuto sur la sécurisation du NAS ?

https://www.nas-forum.com/forum/topic/77493-tuto-pas-à-pas-sécurisation-du-nas-pour-dsm-7/

[darkneo]

Hello a tous,

 

Ayant (encore) des problèmes avec mon renewal, j'ai décidé de franchir le pas de la version docker.. Mais je me retrouve avec exactement le même soucis: Impossible de se logguer pour enregistrer les certificats dans la dernière étape... Quand je lance la commande j'ai l'erreur:

Citation

[Wed Dec 20 15:37:01 UTC 2023] Logging into localhost:5000
Enter OTP code for user 'admin_user_notreal': Enter device name or leave empty for default (CertRenewal): [Wed Dec 20 15:37:01 UTC 2023] Unable to authenticate tohttp://localhost:5000 - check your username & password.
[Wed Dec 20 15:37:01 UTC 2023] If two-factor authentication is enabled for the user, set SYNO_Device_ID.
[Wed Dec 20 15:37:01 UTC 2023] Error deploy for domain:mydomain.ovh
[Wed Dec 20 15:37:01 UTC 2023] Deploy error.

Le user n'a pas de Two factor authentication.... Et j'ai exactement la même erreur avec mon ancien script acme-renew.py.... Des hooks ont été changés pour le prendre que le two factor authent? 

Edit: En regardant un peu plus les logs... C'est étrange car il me trouve pourtant bien les sessionID & Compagnie, mais me dit qu'il n'arrive pas d'authentifier..... :0

Citation

[Wed Dec 20 15:31:07 UTC 2023] url='http://localhost:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=login&format=sid&account=account&passwd=password&otp_code=&enable_syno_token=yes&enable_device_token=yes&device_name=CertRenewal'
[Wed Dec 20 15:31:07 UTC 2023] timeout=
[Wed Dec 20 15:31:07 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header  -L  -g '
[Wed Dec 20 15:31:08 UTC 2023] ret='0'
[Wed Dec 20 15:31:08 UTC 2023] Session ID='UKFMN.wMxscWoB3J4N01003'
[Wed Dec 20 15:31:08 UTC 2023] SynoToken='xKJ08k8FwTYgw'
[Wed Dec 20 15:31:08 UTC 2023] Unable to authenticate to http://localhost:5000 - check your username & password.

 

Modifié le 20 décembre 2023 par darkneo

[Mic13710]

C'est l'IP docker qu'il faut renseigner : 172.17.0.1, pas localhost

[darkneo]

Il y a 23 heures, Mic13710 a dit :

C'est l'IP docker qu'il faut renseigner : 172.17.0.1, pas localhost

J'ai mis localhost pour obfusquer les logs (c'est vrai que j'aurai pu mettre autre chose...) mais en vrai j'ai bien la bonne ip... Pour preuve le SessionID et le Syno Token sont bien renseignés (avec localhost, ils auraient été vides 😉 )

 

J'ai report sur Github le soucis qui, je pense, est du à un mauvais if:

if [ -z "$SYNO_DID" ] && [ -z "$SYNO_Device_ID" ] || [ -z "$sid" ] || [ -z "$token" ]; then

Dans mon cas SYNO_DID et SYNO_Device_ID sont tous les 2 vides, vu que je n'utilise pas le 2 authentication factor, donc je rentre toujours dans cette loop.... car la requete ligne 138 ne me retourne jamais de Device ID.... 😞

 

Modifié le 21 décembre 2023 par darkneo

[Mic13710]

@darkneo autant je peux comprendre qu'on masque une IP publique, mais masquer une ip privée n'a pas de sens.

Si le script demande une authentification OTP, c'est que vous l'avez paramétré dans la configuration.

Dans le fichier ndd.conf du dossier ndd, vous devriez avoir ceci :

Citation

SAVED_SYNO_Username='Votre compte'
SAVED_SYNO_Password='Votre mot de passe'
SAVED_SYNO_DID=''
SAVED_SYNO_TOTP_SECRET=''

 

[darkneo]

Il y a 4 heures, Mic13710 a dit :

@darkneo autant je peux comprendre qu'on masque une IP publique, mais masquer une ip privée n'a pas de sens.

Si le script demande une authentification OTP, c'est que vous l'avez paramétré dans la configuration.

Dans le fichier ndd.conf du dossier ndd, vous devriez avoir ceci :

 

Oui pas faux, mais entre mon NDD, les login/pwd et les ip parfois publiques... Bref.... 

Et non, je n'ai pas activé l'OTP sur mon NAS, mais a force de debug (et de recontruction d'URL), c'est la requpete qui est censée me retourner le Device ID qui ne le fait pas (dans la réponse, il n'y a pas le champ attendu). Certainement car je suis encore sur la version 6 de DSM (pour raison purement domotique, la version 7 et + ayant supprimer des drivers USB pour le RFXCom par exemple).

EDIT: Je vais essayer de tester de plusieurs façon... Mais est ce que je peux techniquement changer un fichier dans un container sans passer par SSH... Car j'avoue ne jamais l'avoir fait (et je n'i qu'un accès remote à mon NAS, le remote SSH n'étant pas activé).

EDIT2: Mon premier test a finalement été le bon.. Et le plus simple! J'ai rajouté un paramètre SAVED_SYNO_Device_ID dans le fichier de conf, et tout s'est déroulé... Presque sans encombre! A la fin, j'ai la fonction de logout qui ne fonctionne pas et me retourne un code 102... Je suppose que ce n'est pas aussi simple en DSM 6, il va falloir que je creuse

 

Modifié le 22 décembre 2023 par darkneo

[Mic13710]

Vous pouvez modifier le fichier de conf puisqu'il est accessible directement dans le dossier Docker/acme. Pour les fichiers autres, pas d'autre solution que de passer en SSH.

Vous n'avez pas de serveur VPN installé sur votre réseau (sur routeur ou sur NAS) ?

Concernant le Device ID, c'est le SYNO_DID du fichier de conf. S'il est vide (comme c'est le cas chez moi), acme ne va normalement pas le demander. Ceci étant dit, il y a eu récemment une maj d'acme.sh qui est sortie après mon dernier renouvellement, et si ça se trouve, le problème que vous rencontrez est peut-être lié à cette nouvelle version.

[darkneo]

Très certainement... Car en Septembre mon renew c'était fait sans soucis, et celui de Décembre était fail (et évidemment j'avais désactivé les notifications, donc je m'en suis aperçu car plus aucune service VPN, remote DSM etc ne fonctionnait).

J'ai fait les propositions de modif dans le Github, on verra si elles sont acceptées, car pour le logout sur DSM 6, il faut utiliser auth.cgi (et non entry.cgi), et j'ai aussi rajouté le SID pour ne tuer que la connection initiée pour le renouvellement du certificat, ce qui me donne:

[Fri Dec 22 13:57:37 UTC 2023] url='http://1.1.1.1:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=logout&_sid=4oM5l6ohX206YB3J4N01003'
[Fri Dec 22 13:57:37 UTC 2023] timeout=
[Fri Dec 22 13:57:37 UTC 2023] curl exists=0
[Fri Dec 22 13:57:37 UTC 2023] mktemp exists=0
[Fri Dec 22 13:57:38 UTC 2023] wget exists=0
[Fri Dec 22 13:57:38 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header  -L  --trace-ascii /tmp/tmp.iuYADzae9v  -g '
[Fri Dec 22 13:57:38 UTC 2023] ret='0'
[Fri Dec 22 13:57:38 UTC 2023] response='{"success":true}'
[Fri Dec 22 13:57:38 UTC 2023] Success

En attendant, j'ai aussi passé l'autoupdate à 0 pour éviter toute prochaine déconvenue tant que la modification n'est pas acceptée/commitée.

 

Et pour info, sans forcément passer par un SSH distant, depuis DSM, on peut aller dans l'interface du container pour lancer une commande custom, taper /bin/sh, ce qui ouvre un terminal directement dans le container (/bin/bash ne fonctionne pas car non installé dans le container).

[darkneo]

Il y a 3 heures, Mic13710 a dit :

Concernant le Device ID, c'est le SYNO_DID du fichier de conf. S'il est vide (comme c'est le cas chez moi), acme ne va normalement pas le demander. Ceci étant dit, il y a eu récemment une maj d'acme.sh qui est sortie après mon dernier renouvellement, et si ça se trouve, le problème que vous rencontrez est peut-être lié à cette nouvelle version.

Pas tout à fait... Le Device ID (dans la version actuelle) est récupéré dans une réponse HTML (ligne 138 du code actuel)

    response=$(_get "$_base_url/webapi/$api_path?api=SYNO.API.Auth&version=$api_version&method=login&format=sid&account=$encoded_username&passwd=$encoded_password&otp_code=$otp_code&enable_syno_token=yes&enable_device_token=yes&device_name=$SYNO_Device_Name")

Or, dans ma réponse, je n'ai pas de champ 'did' ou 'device_id', donc la variable reste systématiquement vide... (soit dit en passant, en plus, elle est totalement inutile car elle n'est pas nécessaire dans les HTML suivantes!)

    id_property='device_id'
    [ "${api_version}" -gt '6' ] || id_property='did'
    SYNO_Device_ID=$(echo "$response" | grep "$id_property" | sed -n 's/.*"'$id_property'" *: *"\([^"]*\).*/\1/p')
    _secure_debug2 SYNO_Device_ID "$SYNO_Device_ID"

 

Modifié le 22 décembre 2023 par darkneo

[mick45000]

Bonjour,

a l'étape 3A du présent tuto  dans le dossier "docker/Acme/votredomaine"

j'ai 4 fichiers mydomain.com.csr
mydomain.com.key
 mydomain.com.csr.conf  mydomain.com.conf 

 

et non pas ceux indiqué dans l'étape.

 

[Mic13710]

@mick45000 c'est que votre certificat n'a pas été créé.

Vous devriez avoir :

ndd.conf
fullchain.cer
ca.cer
ndd.cer
ndd.csc.conf
ndd.csr

Postez une copie du log dans laquelle vous modifiez le ndd pour qu'on puisse voir où est le problème.

 

[mick45000]

@mick13710  merci j'ai refait cela à fonctionner. il me manque à faire la dernière partie pour le renouvellement automatique

[darkneo]

Hello à tous!

Je viens poster ici car je pense qu'être passé sur la version Docker depuis l'ancien script basique a mis la pagaille dans ma config OpenVPN.

J'ai posté un thread dédié ici: 

Pour faire court, j'ai l'impression qu'OpenVPN utilise encore l'ancienne version de mon certificat (qui a expiré) et j'aimerai m'assurer de pouvoir demander l'utilisation du nouveau certificat (mais du coup quels fichier utiliser?). 

Merci d'avance pour votre aide

EDIT: A priori c'est confirmé, même en changeant le certificat dans l'interface Admin, le paquet VPN Server ne semble pas se mettre a jour correctement:

https://serverfault.com/questions/1117955/how-to-use-public-certificates-with-openvpn-on-synology-dsm

Du coup, obligé de passer par un easy RSA? ou de complètement désinstaller VPN Server pour le remettre?

 

Modifié le 26 janvier par darkneo

[Mic13710]

Ou tout simplement rééditer le fichier de conf pour la prise en compte du nouveau certificat.

Raison pour laquelle je n'utilise pas le certificat LE pour le VPN.

On peut utiliser le certificat Synology.com qui a une durée de vie plus longue. Cependant, sa durée a été raccourcie depuis les dernières version de DSM. A titre perso, j'ai créé pour cet usage uniquement un certificat auto-signé dont la durée de vie courre jusqu'en 2038.

[darkneo]

Je pense que c'est ce que je vais faire, car je trouve en plus pas mal de forum (en anglais) qui semblent dire que les certificats LE sont incompatibles avec certaines fonctionnalités d'OpenVPN (j'ai pas tout bien compris...). 

Concernant l'édit du fichier de conf, le "problème" c'est que je n'ai pas les fichiers CRT, PEM, et KEY... Donc il faudrait que je les génère... Donc autant tout refaire au propre avec un autosigné via easy RSA, ce qui me permettra en plus de pouvoir faire des clés pour chaque client que je veux utiliser!

Merci pour l'info 👍

[MilesTEG1]

Bonsoir,

Ayant formaté les disques de mon Syno pour gagner une partition root de 8Go au lieu des 2 pauvres giga, j'ai du refaire mes conteneurs, dont ACME.
Et à l'étape 3B, j'ai une erreur :

20:08:56 -  Script pour paramétrer le déploiement automatique des certificats sur le Syno.
20:08:56 -  Exécution de la commande...
[Mon Mar 25 19:08:56 UTC 2024] Logging into 172.20.0.1:19810
[Mon Mar 25 19:08:57 UTC 2024] Getting certificates in Synology DSM
[Mon Mar 25 19:08:57 UTC 2024] Unable to find certificate: mon-ndd.ovh - Certificat Wildcard Lets Encrypt & $SYNO_Create is not set
[Mon Mar 25 19:08:57 UTC 2024] Error deploy for domain:mon-ndd.ovh
[Mon Mar 25 19:08:57 UTC 2024] Deploy error.
20:08:57 -  Script de création du certificat wildcard terminé

 

En regardant les réponses du sujet, je me suis dit que ça devait être un problème de nom de certificat. Et oui, le nom de la variable SYNO_Certificate doit être identique au nom mis dans DSM, sinon on a l'erreur précédente.

Bref, tout fonctionne bien maintenant 😉 Pour le peu que je vais me servir du certificat de mon .ovh dans DSM 😅

[youbov]

Bonjour, et merci bcp pour ce tuto très simple ! je m'arrachais les cheveux avec l'ancienne méthode en vain en plus 😄

[Mic13710]

Pour info : la console d'OVH a changé.

L'url d'accès aux API est maintenant celle-ci :

https://api.ovh.com/console/?section=%2Fme&branch=v1#get-/me/api/application

La présentation est très différente de l'ancienne mais on s'y retrouve assez facilement.

A noter que la commande "Execute" est remplacée par "Try"

L'ancienne console continue de fonctionner pour quelques temps encore à cette url :

https://eu.api.ovh.com/console#/me/api/application~GET

[firlin]

@Mic13710, meci pour info.
Ceux qui utilise le déploiement automatique du certificat vous pouvez vérifier que cela fonctionne bien chez vous ? (section 3 B)
Car je viens d'avoir un nas, voir deux nas ou cela n'as plus fonctionné, j'ai du faire la mise à jour à la main. Sachant qu'un est distant donc un peu compliqué.
Le dernier la maj aurait du ce faire cette semaine. entre le 19 et le 22mai.

 

[Mic13710]

@firlin j'ai eu des problèmes de déploiement automatique sur le 220+ lors du dernier renouvellement. Le certificat était OK.

Même manuellement, ça ne fonctionnait pas car le script n'arrivait pas à récupérer le SYNO_Session_ID et le SYNO_SynoToken ce qui bloquait le déploiement.

Regarde tes logs, il est probable que ces deux variables soient nulles et que tu ais ce message : "Unable to authenticate to http://172.17.0.1:5000, you may report the full log to the community."

Ce que j'ai fait, mais n'a pas servi à grand chose. https://github.com/acmesh-official/acme.sh/issues/2727

Mais après quelques jours et sans avoir changé quoi que ce soit, le déploiement manuel a fonctionné. Les mystères de l'informatique...

A voir lors du prochain renouvellement.

[Jeff777]

il y a une heure, firlin a dit :

Ceux qui utilise le déploiement automatique du certificat vous pouvez vérifier que cela fonctionne bien chez vous

Bonjour,

Je te dirai le3 juin (prochain renouvellement auto). Mais avec ce tuto (donc zone hébergée), pas certain que ce soit pertinent 🤣.

 

[firlin]

Ok @Mic13710,
Par contre je viens de voir que j'ai pas de fichier log dans mon répertoire Acme.
 

[Mic13710]

@firlin il faut dé-commenter la ligne LOG_FILE="/acme.sh/acme.sh.log" dans l'account.conf

[firlin]

Vu @Mic13710 j’avais pas le L du log

[firlin]

je viens de regarde le log fraichement crée cette nuit, j'ai pas la ligne que tu signale @Mic13710.
A vois si cela fonctionne dans le temps.