Déploiement certificat LE, 2FA et variable SYNO_TOTP_SECRET

[oracle7]

Bonjour,

Je viens de découvrir suite au process de renouvellement de mon certificat LE par le script acme.sh que le script de déploiement (synology_dsm.sh) du certificat prend en compte depuis peu une nouvelle variable d'environnement SYNO_TOTP_SECRET liée à l'authentification à 2 facteurs lorsque celle-ci est activée sur le NAS.

Sans avoir défini cette variable d'environnement SYNO_TOTP_SECRET on récolte lors du renouvellement du certificat dans le log un message du type :

Citation

[Mon Feb 21 00:01:28 CET 2022] token
[Mon Feb 21 00:01:28 CET 2022] Unable to authenticate to localhost:5000 using http.
[Mon Feb 21 00:01:28 CET 2022] Check your username and password.
[Mon Feb 21 00:01:28 CET 2022] If two-factor authentication is enabled for the user, set SYNO_TOTP_SECRET.
[Mon Feb 21 00:01:28 CET 2022] Error deploy for domain:ndd.fr
[Mon Feb 21 00:01:28 CET 2022] Deploy error.

J'ai bien essayé d'exporter cette variable préalablement à un renouvellement en la renseignant avec la clé secret qui m'avait permit d'initialiser Google Authenticator sur mon tél portable, mais malheureusement cela ne marche pas.

D'où ma question, est-ce que l'un d'entre vous sait-il comment renseigner cette variable SYNO_TOTP_SECRET càd quelle valeur exactement faut-il lui donner ? et où la trouver ? J'avoue que là je sèche ...

@Einsteinium Une idée peut-être ?

Cordialement

oracle7😉

Modifié le 21 février 2022 par oracle7

[Einsteinium]

Bonjour @oracle7

Je n’ai rien vue dans ce sens encore, je regarderais au soir pour voir, car il n’y a rien côté doc github qui reste sur l’ancienne variable syno_did

[MilesTEG1]

@oracle7 Dans le log de mon acme.sh, je n'ai pas vu non plus de message comme le tient.

[cadkey]

https://git.tool.ykziao.com/ykxiao/acme/commit/c959d64099b72aba435288f87936a05c1238b9d9

[oracle7]

Il y a 16 heures, oracle7 a dit :

SYNO_TOTP_SECRET

Bonjour,

@Einsteinium

J'ai épluché Github et Google sur le sujet et je n'ai rien trouvé. Pour l'instant, on voit cela uniquement au travers de l'issue #3807 et des corrections faites au script de déploiement, La doc effectivement n'en fait pas encore mention.

@MilesTEG1

Il y a 3 heures, MilesTEG1 a dit :

Dans le log de mon acme.sh, je n'ai pas vu non plus de message comme le tient.

Si tu utilises la 2FA alors attends le renouvellement de ton certificat et tu verras que le déploiement du certificat plante avec ce message.

@cadkey

Merci pour le lien mais j'avais déjà donné le lien "officiel" dans la variable : SYNO_TOTP_SECRET

Cordialement

oracle7😉

[Einsteinium]

@oracle7 Je viens de regardé… si j’ai bien compris on peut toujours utilisé le did ou ce nouveau paramètres qui demande alors le totp pour générer la code.

Maintenant suite à ton retour on dirais que le did ne marche pas… bref renseigne le totp (récupère le d’un client enregistré par contre, car je vois pas comment en validé un nouveau là comme ça… (peu etre à la génération ?), c’est la longue suite de caractère qui apparaît en // du QR code et qui te permet de générer les codes dans les clients.

[cadkey]

il y a 2 minutes, oracle7 a dit :

Merci pour le lien mais j'avais déjà donné le lien "officiel" dans la variable : SYNO_TOTP_SECRET

Bon ben tu as la correction du coup.

[MilesTEG1]

@oracle7 Lorsque tu parles de 2FA, c'est pour le compte du NAS ou le compte OVH ?
PS : j'ai utilisé la méthode docker pour acme.

[oracle7]

@MilesTEG1

Bonjour,

il y a 1 minute, MilesTEG1 a dit :

tu parles de 2FA, c'est pour le compte du NAS ou le compte OVH ?

C'est lorsque la double authentification est activée pour le NAS.

Aucun impact ni rapport avec la 2FA appliquée au compte OVH. Chez OVH la 2FA ne concerne que l'accès global à OVH et pas à la zone DNS de ton domaine.

Cordialement

oracle7😉

[MilesTEG1]

il y a 53 minutes, oracle7 a dit :

@MilesTEG1

Bonjour,

C'est lorsque la double authentification est activée pour le NAS.

Aucun impact ni rapport avec la 2FA appliquée au compte OVH. Chez OVH la 2FA ne concerne que l'accès global à OVH et pas à la zone DNS de ton domaine.

Cordialement

oracle7😉

Ok, bah reste à voir quand mon certificat sera renouvelé...

@Einsteinium c'est censé apparaitre comment dans le fichier log quand le certificat est renouvelé ?

[oracle7]

Bonjour,

@Einsteinium

il y a 32 minutes, Einsteinium a dit :

si j’ai bien compris on peut toujours utilisé le did ou ce nouveau paramètres qui demande alors le totp pour générer la code.

Non ce n'est pas cela. Si la 2FA est activée sur le NAS, le script de déploiement va alors chercher la clé OTP secrète stockée dans la variable SYNO_TOTP_SECRET. Cela lui permet alors de générer tout seul le code OTP de validation pour se connecter au compte du NAS : il utilise pour cela l'outil interne "oathtool" :

otp_code=""
  if [ -n "$SYNO_TOTP_SECRET" ]; then
    otp_code="$(oathtool --base32 --totp "${SYNO_TOTP_SECRET}" 2>/dev/null)"
  fi

Si tu n'utilises pas la 2FA alors la variable SYNO_TOTP_SECRET doit être de toute façons présente et initialisée à "vide".

Donc finalement de ce que je comprend, si la 2FA est activée sur le NAS, en plus de l'export de la variable SYNO_DID, c'est un paramètre supplémentaire à introduire (export SYNO_TOPT_SECRET='xxxxxxxx') dans nos scripts avant la commande de déploiement du certificat.

Sinon j'ai récupéré la clé secrète à partir de mon compte utilisateur et renseigné la variable SYNO_TOTP_SECRET avec et exporté cette dernière. J'ai aussi rajouté cette variable dans mon fichier ndd.tld.conf. Mais cela n'a pas marché. Je dois rater un truc mais quoi ?

Comme je ne veux pas griller mes cartouches en demandes au prés de LE, j'arrête là les tests en attendant de trouver une solution.

@MilesTEG1

Attention, cela ne semble pas bloquer le renouvellement du certificat, simplement le déploiement du certificat ne se fait pas si cette variable d'environnement n'est pas correctement préalablement renseignée quand on utilise la 2FA.

@cadkey

Tu n'as pas compris mais pas grave ....

Je ne cherchais pas la correction effectuée puisque je l'avais trouvée, c'est juste qu'elle m'a permis en la voyant de comprendre pourquoi j'avais eut le message d'erreur dans le log et d'où ensuite ma question sur ce post.

Cordialement

oracle7😉

[MilesTEG1]

il y a 11 minutes, oracle7 a dit :

Attention, cela ne semble pas bloquer le renouvellement du certificat, simplement le déploiement du certificat ne se fait pas si cette variable d'environnement n'est pas correctement préalablement renseignée quand on utilise la 2FA.

Haaa 🙂 Avec les explications et l'extrait de script que tu as mis, j'ai compris 🙂

Es-tu sûr que ça va bloquer avec la méthode Docker ?

Si oui, @Einsteinium va devoir mettre à jour son tuto 😄 😜

[oracle7]

@MilesTEG1

Bonjour,

il y a 37 minutes, MilesTEG1 a dit :

Es-tu sûr que ça va bloquer avec la méthode Docker ?

Si oui, @Einsteinium va devoir mettre à jour son tuto 😄 😜

A mon humble avis, OUI y-a pas de raison contre car sauf erreur de ma part,  il utilise aussi le script de déploiement officiel (synology_dsm.sh) qui impose cela.

Et donc tout comme moi il devra se fendre d'un addendum à son TUTO, sinon tu verras immanquablement fleurir les posts sur ce sujet ...

Cordialement

oracle7😉

Modifié le 22 février 2022 par oracle7

[Kramlech]

il y a une heure, MilesTEG1 a dit :

Es-tu sûr que ça va bloquer avec la méthode Docker ?

En tout cas, chez moi avec la méthode Docker, le renouvellement a eu lieu il y a 10 jours sans problème ...

[oracle7]

@Kramlech

Bonjour,

Ce n'est pas un problème de renouvellement, celui-ci se fait bien, mais c'est le déploiement du certificat sur le NAS qui ne se fait pas si tu utilises la 2FA. Chez moi, le renouvellement s'effectue bien lors de mes tests mais le nouveau certificat n'est pas réaffecté aux services lors du déploiement.

Cordialement

oracle7😉

[Kramlech]

@oracle7Quand je disais que le renouvellement à eu lieu, je voulais bien entendu dire renouvellement + déploiement... 😉

Il y a 1 heure, oracle7 a dit :

Si tu n'utilises pas la 2FA alors la variable SYNO_TOTP_SECRET doit être de toute façons présente et initialisée à "vide".

En fait, je n'utilise pas la 2FA, mais si j'ai bien compris le sens de cette phrase, le fait de ne pas avoir cette variable devrait faire planter le script ...

C'est pour cela que je me suis permis cette petit information.

[oracle7]

@Kramlech

Bonjour,

En fait, de ce que j'ai compris c'est la présence du couple de variables SYNO_DID et SYNO_TOTP_SECRET qui est contrôlée dans le script de déploiement. Si la première est renseignée alors la seconde doit l'être. Si aucune des deux n'est présente (c'est le cas lorsque l'on utilise pas comme toi la 2FA) alors pas de problème pour le déploiement.

Cordialement

oracle7😉

[MilesTEG1]

il y a 32 minutes, Kramlech a dit :

En tout cas, chez moi avec la méthode Docker, le renouvellement a eu lieu il y a 10 jours sans problème ...

Comment je peux voir quand a eu lieu le dernier renouvellement ?

[cadkey]

Il y a 2 heures, oracle7 a dit :

Tu n'as pas compris mais pas grave ....

Je ne cherchais pas la correction effectuée puisque je l'avais trouvée, c'est juste qu'elle m'a permis en la voyant de comprendre pourquoi j'avais eut le message d'erreur dans le log et d'où ensuite ma question sur ce post.

Si si ne t'inquiete pas, j'avais compris.
Le correctif fonctionne, c'est parfait.

[oracle7]

Bonjour,

@MilesTEG1

Regardes tout bêtement la date des fichiers de ton certificat, non ?

@cadkey

il y a 1 minute, cadkey a dit :

Le correctif fonctionne, c'est parfait.

????, j'ai du mal à te suivre là ...

Cordialement

oracle7😉

[MilesTEG1]

il y a 2 minutes, oracle7 a dit :

@MilesTEG1

Regardes tout bêtement la date des fichiers de ton certificat, non ?

Oh purée 😆 Pourquoi je ne suis pas allé voir dans ce dossier XD

Du coup à priori il date du 9 janvier. (je ne sais pas pourquoi le .key n'a pas une date plus récente... le 17/05 c'est quand j'ai mis en place le script.)

Du coup, dans le log j'ai parcouru à la date du 09/01 et j'ai repéré ceci qui me semble indiqué un renouvellement de certificat :

[Sun Jan  9 00:47:02 UTC 2022] Cert success.
[Sun Jan  9 00:47:02 UTC 2022] Your cert is in: /acme.sh/mon-ndd.ovh/mon-ndd.ovh.cer
[Sun Jan  9 00:47:02 UTC 2022] Your cert key is in: /acme.sh/mon-ndd.ovh/mon-ndd.ovh.key
[Sun Jan  9 00:47:02 UTC 2022] The intermediate CA cert is in: /acme.sh/mon-ndd.ovh/ca.cer
[Sun Jan  9 00:47:02 UTC 2022] And the full chain certs is there: /acme.sh/mon-ndd.ovh/fullchain.cer
[Sun Jan  9 00:47:02 UTC 2022] _on_issue_success

 

[oracle7]

@MilesTEG1

Bonjour,

Pour le fichier .key c'est normal, le renouvellement n'a pas d'impact sur lui. Le certificat utilise toujours la même clé.

Cordialement

oracle7😉

Modifié le 22 février 2022 par oracle7

[oracle7]

@Einsteinium

Bonjour, D'après toi l'outil "oathtool" utilisé par le script de déploiement pour générer le code OTP, il est inclus dans le package acme.sh (j'ai pas vu non plus) ou devrait-il être présent sur le NAS dans DSM car là, moi sous DSM 6.x, je ne le l'ai pas trouvé en lançant une recherche globale depuis le répertoire racine "/" (sous SSH). Mais peut-être qu'il existe sous DSM 7 ? ce que je ne peux vérifier à cette heure.

Car pourtant il fait partie des "dependencies" du script synology_dsm.sh :

Son absence de DSM 6.x pourrait expliquer finalement le message d'erreur, non ? puisque le code OTP ne serait donc pas généré. Ton avis STP ?

Cordialement

oracle7😉

Modifié le 22 février 2022 par oracle7

[Einsteinium]

Il y a 3 heures, oracle7 a dit :

Non ce n'est pas cela. Si la 2FA est activée sur le NAS, le script de déploiement va alors chercher la clé OTP secrète stockée dans la variable SYNO_TOTP_SECRET. Cela lui permet alors de générer tout seul le code OTP de validation pour se connecter au compte du NAS : il utilise pour cela l'outil interne "oathtool" :

Alors ils sont pas clair car on ils disent le did pour passé le 2fa, le totp pour le générer ^^’

# SYNO_DID - device ID to skip OTP - defaults to empty

# SYNO_TOTP_SECRET - TOTP secret to generate OTP - defaults to empty

 

il y a 35 minutes, oracle7 a dit :

Son absence de DSM 6.x pourrait expliquer finalement le message d'erreur, non ? puisque le code OTP ne serait donc pas généré. Ton avis STP ?

 

Alors dans ta méthode il doit prendre sur l’hôte, j’ai pas regardé le script (n’y par quoi passe le syno =P) pour docker qui est sans super droit, il est (forcément) inclus :

https://github.com/acmesh-official/acme.sh/blob/master/Dockerfile

Bref du coup de tes déductions on peut dire que sous dsm 6 et double auth, il faudra le faire par docker obligatoirement ^^

[oracle7]

@Einsteinium

Bonjour,

il y a 7 minutes, Einsteinium a dit :

Bref du coup de tes déductions on peut dire que sous dsm 6 et double auth, il faudra le faire par docker obligatoirement ^^

Effectivement, de toutes façons c'est ce que je comptais faire lors de ma migration vers DSM 7.

Mais quand même indépendamment de la version de DSM, comment vont faire ceux qui ne peuvent pas (ou ne veulent pas) utiliser docker ? Cela va râler dans les chaumières ...🥴

Car ce foutu outil "oathtool" n'est pas inclus dans DSM  ni dans le package de base du script acme.sh (du moins pour l'instant).

Cordialement

oracle7😉