Aller au contenu

Messages recommandés

Posté(e) (modifié)

Bonjour @oracle7,

J'ai une erreur inédite sur l’exécution su script :

-- Le nom de domaine (ndd.tld) est errone ou mal configure avec acme.sh.
-- Arret du script de renouvellement du certificat


Process menant à cette erreur

Voici ce que j'ai fait pour essayer de corriger (sous PuTTY en root) :

cd /volume1
cd Certs/Acme_install
cd acme.sh-master

ACME_HOME="/usr/local/share/acme.sh"
CERT_HOME="/volume1/Certs"

cd $ACME_HOME

export OVH_END_POINT=ovh-eu
export OVH_AK="votre application key"
export OVH_AS="votre application secret"
export OVH_CK="votre consumer key"

cd $ACME_HOME

export CERT_DOMAIN="votre-domaine.tld"
export CERT_WDOMAIN="*.votre-domaine.tld"
export CERT_DNS="dns_ovh"
export SYNO_DID=xxx

pwd

export SYNO_Scheme="http"
export SYNO_Hostname="localhost"
export SYNO_Port="5000"
export SYNO_Username='DSM_Admin_Username'
export SYNO_Password='DSM_Admin_Password!123'
export SYNO_Certificate="ACME_Wilcard_LE_*.ndd.tld"
export SYNO_Create=1

./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm

J'obtiens alors :

[Sun Mar 20 12:41:24 CET 2022] Logging into localhost:5000
[Sun Mar 20 12:41:25 CET 2022] Getting certificates in Synology DSM
[Sun Mar 20 12:41:26 CET 2022] Generate form POST request
[Sun Mar 20 12:41:26 CET 2022] Upload certificate to the Synology DSM
[Sun Mar 20 12:42:29 CET 2022] http services were restarted
[Sun Mar 20 12:42:30 CET 2022] Success

C'est encourageant et je poursuis donc avec :

cd /usr/local/share/acme.sh
./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh

J'obtiens alors :

[Sun Mar 20 12:50:37 CET 2022] Installing from online archive.
[Sun Mar 20 12:50:37 CET 2022] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz
[Sun Mar 20 12:50:38 CET 2022] Extracting master.tar.gz
[Sun Mar 20 12:50:38 CET 2022] It is recommended to install socat first.
[Sun Mar 20 12:50:38 CET 2022] We use socat for standalone server if you use standalone mode.
[Sun Mar 20 12:50:38 CET 2022] If you don't use standalone mode, just ignore this warning.
[Sun Mar 20 12:50:38 CET 2022] Installing to /usr/local/share/acme.sh
[Sun Mar 20 12:50:38 CET 2022] Installed to /usr/local/share/acme.sh/acme.sh
[Sun Mar 20 12:50:38 CET 2022] Good, bash is found, so change the shebang to use bash as preferred.
[Sun Mar 20 12:50:41 CET 2022] OK
[Sun Mar 20 12:50:41 CET 2022] Install success!
[Sun Mar 20 12:50:41 CET 2022] Upgrade success!

C'est de nouveau encourageant.
Je suis dans volume1/Scripts et j’exécute la commande suivante :

python acme_renew.py -t ndd.tld

J'obtiens alors :

-- Le nom de domaine (ndd.tld) est errone ou mal configure avec acme.sh.
-- Arret du script de renouvellement du certificat


État de m configuration

Je suis encore sous DMS 6.

Mon fichier account.conf dans usr/local/share/acme.sh est le suivant :

LOG_FILE='/volume1/Certs/Acme_renew/acmelog'
#LOG_LEVEL=1

AUTO_UPGRADE='1'

#NO_TIMESTAMP=1

   
CERT_HOME='/volume1/Certs'
ACCOUNT_EMAIL='email@orange.fr'
UPGRADE_HASH='XXX'
DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'
SAVED_OVH_AK='XXX'
SAVED_OVH_AS='XXX'
USER_PATH=':/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin'

As tu une idée de ce qui cloche ?

Merci d'avance,

Modifié par TuringFan
Posté(e)

@TuringFan

Bonjour,

Ton fichier 'account.conf' n'est pas bon, il te manque ces variables d'environnement :

SAVED_DID='------------------XXXDIDXXX---------------------'
OVH_CK='XXXXX'

Attention : si tu utilises la 2FA, saches que acme a récemment modifié le script de déploiement synology_dsm.sh. Celui-ci impose l'usage de la clé secrète de la 2FA au travers d'une variable d'environnement SYNO_TOTP_SECRET. Sauf que le script python ne gère pas cette nouvelle variable. Du coup, le déploiement du certificat ne se fait plus automatiquement. Heureusement cela ne bloque pas le renouvellement sur certificat, juste son déploiement.

Il suffit alors de prendre les fichiers du certificat dans /volume1/Certs/tonDomaine.tld et de la recharger manuellement sur le NAS.

Cordialement

oracle7😉

 

Posté(e) (modifié)
il y a 9 minutes, oracle7 a dit :
OVH_CK='XXXXX'

Merci. Est-ce "OVH_CK" ou "SAVED_OVH_CK" ?

Je vais essayer le reste et je te dis.

il y a 14 minutes, oracle7 a dit :

Attention : si tu utilises la 2FA, saches que acme a récemment modifié le script de déploiement synology_dsm.sh. Celui-ci impose l'usage de la clé secrète de la 2FA au travers d'une variable d'environnement SYNO_TOTP_SECRET. Sauf que le script python ne gère pas cette nouvelle variable. Du coup, le déploiement du certificat ne se fait plus automatiquement.

@oracle7

Je viens de modifier mon fichier acount.conf en ajoutant SAVEC_DID et SAVED_OHV_CK et j'ai toujours le même problème.

Dois-je aller modifier cette fameuse variable SYNO_TOTP_SECRET ?Si oui où la trouver ? Dans acme.sh ?

Merci d'avance,

Modifié par TuringFan
Posté(e)

@TuringFan

Bonjour,

Dans le fichier account.conf c'est bien "OVH_CK". C'est une particularité/anomalie acme !

Je crains que tu ne confondes avec "SYNO_OVH_AK" et "SYNO_OVH_AS" ...

Cordialement

oracle7😉

Posté(e) (modifié)

Merci @oracle7 mon certificat est bien à jour !

Voici ce que j'ai fait (en espérant que ça aidera) :

J'ai complété mon fichier account.conf pour en avoir un de la forme :

LOG_FILE='/volume1/Certs/Acme_renew/acmelog'

#LOG_LEVEL=1
AUTO_UPGRADE='1'

#NO_TIMESTAMP=1
CERT_HOME='/volume1/Certs'

ACCOUNT_EMAIL='email@orange.fr'
UPGRADE_HASH='XXX'
DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'
SAVED_OVH_AK='XXX'
SAVED_OVH_AS='XXX'
SAVED_OVH_CK='XXX'
SAVED_DID='XXX'
USER_PATH=':/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin'

A noter c'est bien une variable "SAVED_OVH_CK" qui y apparait et non "OVH_CK" : j'avais lancé dans cette config en attendant ta réponse et ça a fonctionné ... bizarre ...

J'ai exécuté la commande deploy
:

./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm

pour obtenir

[Sun Mar 20 12:41:24 CET 2022] Logging into localhost:5000
[Sun Mar 20 12:41:25 CET 2022] Getting certificates in Synology DSM
[Sun Mar 20 12:41:26 CET 2022] Generate form POST request
[Sun Mar 20 12:41:26 CET 2022] Upload certificate to the Synology DSM
[Sun Mar 20 12:42:29 CET 2022] http services were restarted
[Sun Mar 20 12:42:30 CET 2022] Success

Pas certain de bien comprendre pourquoi j'obtiens un "success" ici car (i) si je comprends bien mon certificat n'était alors pas encore à jour et (ii) comme tu l'avais deviné j'utilise une connexion avec 2FA (ce qui semble aujourd'hui poser problème pour le déploiement).

J'ai ensuite lancé une MAJ d'ACME

cd /usr/local/share/acme.sh
./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh

Pour obtenir :

[Sun Mar 20 12:50:37 CET 2022] Installing from online archive.
[Sun Mar 20 12:50:37 CET 2022] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz
[Sun Mar 20 12:50:38 CET 2022] Extracting master.tar.gz
[Sun Mar 20 12:50:38 CET 2022] It is recommended to install socat first.
[Sun Mar 20 12:50:38 CET 2022] We use socat for standalone server if you use standalone mode.
[Sun Mar 20 12:50:38 CET 2022] If you don't use standalone mode, just ignore this warning.
[Sun Mar 20 12:50:38 CET 2022] Installing to /usr/local/share/acme.sh
[Sun Mar 20 12:50:38 CET 2022] Installed to /usr/local/share/acme.sh/acme.sh
[Sun Mar 20 12:50:38 CET 2022] Good, bash is found, so change the shebang to use bash as preferred.
[Sun Mar 20 12:50:41 CET 2022] OK
[Sun Mar 20 12:50:41 CET 2022] Install success!
[Sun Mar 20 12:50:41 CET 2022] Upgrade success!

J'ai exporté mes variables :

cd /volume1
cd Certs/Acme_install
cd acme.sh-master

ACME_HOME="/usr/local/share/acme.sh"
CERT_HOME="/volume1/Certs"

cd $ACME_HOME

export OVH_END_POINT=ovh-eu
export OVH_AK="votre application key"
export OVH_AS="votre application secret"
export OVH_CK="votre consumer key"

cd $ACME_HOME

export CERT_DOMAIN="votre-domaine.tld"
export CERT_WDOMAIN="*.votre-domaine.tld"
export CERT_DNS="dns_ovh"
export SYNO_DID=xxx

pwd

export SYNO_Scheme="http"
export SYNO_Hostname="localhost"
export SYNO_Port="5000"
export SYNO_Username='DSM_Admin_Username'
export SYNO_Password='DSM_Admin_Password!123'
export SYNO_Certificate="ACME_Wilcard_LE_*.ndd.tld"
export SYNO_Create=1

J'ai paramétré ACME pour utiliser LE et non ZeroSSL comme indiqué dans ton edit de juin 2021 :

cd $ACME_HOME

./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt
[Sun Mar 20 15:32:52 CET 2022] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory

J'ai lancé un renouvellement :

./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"

[Sun Mar 20 15:34:15 CET 2022] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Sun Mar 20 15:34:15 CET 2022] Domain key exists, do you want to overwrite the key?
[Sun Mar 20 15:34:15 CET 2022] Add '--force', and try again.
[Sun Mar 20 15:34:15 CET 2022] Create domain key error.
[Sun Mar 20 15:34:15 CET 2022] Please check log file for more details: /volume1/Certs/Acme_renew/acmelog
[Sun Mar 20 15:34:15 CET 2022] Creating domain key

./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --force

Et miracle cela a fonctionné !

J'ai ensuite utilisé WinSCP pour télécharger les fichier du certificat et les importer à la main dans mon NAS et mon Routeur.

Maintenant mon navigateur m'affiche bien un accès en https à SRM et DSM comme sécurisé !

Merci encore !

 

------------------------------------------------------------------------------------------------------------------------------

@oracle7

Au regard du nouveau paradigme et des évolutions de Synology et DSM je comprends que je devrais maintenant systématiquement importer le Certificat (ce que je faisais déjà pour mon Routeur) sur mon NAS.

Du coup est-ce que cela ne vaut il pas le coup de faire sauter la tache, ACME, le script ACME_renew.py fait avec @bruno78 et de faire tous les 3 mois un renouvellement LE wilcard à la main ?

Sauf erreur de ma part l'interface de Synology ne permet de le faire que pour un "sous" domaine Synology.

Comment faire un renouvellement à la main sur un domaine quelconque "*.ndd.tld" ?

Je vois par ailleurs beaucoup de tuto, forum etc. qui parlent de certificat wildcard avec Synology : n'existe-t-il pas une solution stable adaptée pour le commun des mortelles (simple à implémenter) ? Même payante ? Avec des évolutions apportées par DSM 7 (ça pourrait être un déclencheur pour faire la migration chez moi) ?

Merci d'avance

Modifié par TuringFan
Posté(e) (modifié)

@TuringFan

Bonjour,

il y a une heure, TuringFan a dit :

A noter c'est bien une variable "SAVED_OVH_CK" qui y apparait et non "OVH_CK" : j'avais lancé dans cette config en attendant ta réponse et ça a fonctionné ... bizarre ...

Tu est vraiment sûr de ton coup là ?

Pour moi ton fichier 'account.conf' n'est pas bon, ce n'est pas la variable SYNO_OVH_CK qu'il faut mettre mais la variable OVH_CK. Tu verras bien au prochain renouvellement si tu as l'erreur ou pas. Je ne peux te dire mieux.

OVH_CK='XXXXX'

 

il y a une heure, TuringFan a dit :

Pas certain de bien comprendre pourquoi j'obtiens un "success" ici car (i) si je comprends bien mon certificat n'était alors pas encore à jour et (ii) comme tu l'avais deviné j'utilise une connexion avec 2FA (ce qui semble aujourd'hui poser problème pour le déploiement).

Alors là moi non plus je ne comprends pas ! Car nous sommes plusieurs à avoir eut le soucis. C'est vraiment étonnant que ce déploiement se soit effectué sans encombres, oui, bizarre, bizarre ...

il y a une heure, TuringFan a dit :

Du coup est-ce que cela ne vaut il pas le coup de faire sauter la tache, ACME, le script ACME_renew.py fait avec @bruno78 et de faire tous les 3 mois un renouvellement LE wilcard à la main ?

Le script est là justement pour ne pas avoir à le faire à la main. Maintenant il ne déploie plus, c'est tout. Mais si cela t'amuse de le faire à main, rien ne t'en empêche. Juste plus contraignant car il faut y penser d'une part au bon moment et remettre les mains dans le cambouis d'autre part pour le faire.Mais c'est toi qui voit ...

il y a une heure, TuringFan a dit :

Au regard du nouveau paradigme [...] sur mon NAS.

OUI.

Enfin, a priori tout cela se simplierait avec la méthode acme sous docker mais comme je suis encore sous DSM 6, je ne puis te le confirmer ou te l' infirmer.

Cordialement

oracle7😉

 

 

Modifié par oracle7
  • 3 mois après...
Posté(e) (modifié)

Salut @oracle7

Le script fonctionnait plutôt bien de mon côté pendant 1 an.

Mais depuis aujourd'hui, j'obtiens systématiquement ce message d'erreur et je me retrouve dans l'impossibilité d'obtenir un nouveau certificat...

Message d'erreur:


[Tue Jul  5 09:56:37 CEST 2022] Add txt record error.
[Tue Jul  5 09:56:37 CEST 2022] Error add txt for domain:_acme-challenge.XXXXX.NDD



Apparemment, ça coince au niveau l'ajout et vérification du TXT record sur OVH...

Une solution ou piste pour corriger mon problème?

Merci.

 

EDIT: Quand je fais le renouvellement manuellement sur WinSCP (exécution du script Python en mode "forced"), j'arrive à obtenir un nouveau certificat...
Où est-ce que cela coince du coup?

Modifié par Stixen92
  • 3 semaines après...
Posté(e)

Bonjour @oracle7,

Depuis que je suis passé sous DSM 7 et corrigé la tâche du renouvellement de certificat comme signalé dans un autre post, mon NAS renouvelle le certificat chaque semaine.  Comment faire pour que cela soit tous les 2 mois environ ?

Autre question, le tuto est pratique lorsqu'on est chez OVH.  J'envisage de migrer vers Infomaniak.  Que dois-je faire comme modification pour le certificat ?

Merci pour ton aide.

  • 2 semaines après...
Posté(e)

@oracle7

Je viens d'y passer quelque heures et je suis perdu.

J'ai suivi le tuto (enfin il me semble) et quand j'exécute :

$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt

J'obtiens juste :

[Sat Aug  6 02:31:10 CEST 2022] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory

Mais pas la suite attendue

si je mets sudo avant d'executer le script, j'obtiens cela

touch: cannot touch '/root/.acme.sh/account.conf': No such file or directory
grep: /root/.acme.sh/account.conf: No such file or directory
grep: /root/.acme.sh/account.conf: No such file or directory
./acme.sh: line 2271: /root/.acme.sh/account.conf: No such file or directory
grep: /root/.acme.sh/account.conf: No such file or directory

Du coup j'ai ouvert le acme.sh et j'ai modifié comme suit:

#DEFAULT_INSTALL_HOME="$HOME/.$PROJECT_NAME"
DEFAULT_INSTALL_HOME=$ACME_HOME

Je n'ai plus les erreurs de fichier non trouvé mais je reste avec le résultat précédent et pas de certificat

Pour les actions à faire avant notamment :

$ export CERT_DOMAIN="votre-domaine.tld"
$ export CERT_WDOMAIN="*.votre-domaine.tld"

On ne met pas de " autour du vrai nom de domaine ?

$ export CERT_DNS="dns_ovh"

Je met cette ligne exactement ou il faut mettre une valeur à la place de "dns_ovh" ? j'ai essayé en mettant dns17.ovh.net mais j'ai eu le même résultat

Merci d'avance

 

 

Posté(e)
Le 05/07/2022 à 11:14, Stixen92 a dit :

Une solution ou piste pour corriger mon problème?

Généralement ce genre d'erreur est lié à un problème de token, est-ce que par hasard tu n'aurais pas mis une durée d'un an sur celui-ci et que du coup logiquement il n'est plus actif ?

Le 25/07/2022 à 11:43, Pinpon_112 a dit :

Comment faire pour que cela soit tous les 2 mois environ ?

A moins de forcer la commande acme, avec le paramètre --force, il n'y a aucune raison que ça renouvelle plus tôt que tous les 60 jours. Car le script vérifie la date d'émission du certificat avant de le renouveler, s'il a moins de 60 jours il s'arrête automatiquement, sauf à le forcer.

Le 25/07/2022 à 11:43, Pinpon_112 a dit :

Autre question, le tuto est pratique lorsqu'on est chez OVH.  J'envisage de migrer vers Infomaniak.  Que dois-je faire comme modification pour le certificat ?

Voir la doc : https://github.com/acmesh-official/acme.sh/wiki/dnsapi#119-use-infomaniakcom-api

Posté(e)

@Tex5 Le tutoriel a été annoté mais pas corrigé intégralement. Quand tu ajoutes --set-default-CA tu définis le CA que tu vas utiliser par défaut (Letsencrypt dans ton cas et pas ZeroSSL qui est le CA par défaut d'acme.sh depuis quelques temps).

Cette opération ne se fait qu'une fois, par la suite soit tu ne précises rien (plus de --set-default-CA --server Letsencrypt), soit tu enlèves juste --set-default-CA et laisse --server letsencrypt pour être sûr que c'est bien LE qui est utilisé (c'est ce que je fais chez moi).

Concernant les fichiers dans /root, assure-toi que le chemin est bien défini, je crois que c'est la destination par défaut si le chemin que tu lui indiques n'est pas trouvé.

Logiquement tu n'as pas à modifier le script, juste les variables éventuellement. Si elles ont changé de nom depuis le temps, il suffit de modifier le nom des variables que tu exportes dans le shell.

Posté(e)

Hello,

Il y a 2 heures, .Shad. a dit :
Le 25/07/2022 à 11:43, Pinpon_112 a dit :

Comment faire pour que cela soit tous les 2 mois environ ?

A moins de forcer la commande acme, avec le paramètre --force, il n'y a aucune raison que ça renouvelle plus tôt que tous les 60 jours. Car le script vérifie la date d'émission du certificat avant de le renouveler, s'il a moins de 60 jours il s'arrête automatiquement, sauf à le forcer.

Merci pour l'aide.  Voici la commande que j'ai :

bash /usr/local/share/acme.sh/acme.sh --cron --force --debug --home /usr/local/share/acme.sh/

Si je te comprend bien alors, je dois juste enlever '--force' et cela reviendra à la normale ?

Il y a 2 heures, .Shad. a dit :
Le 25/07/2022 à 11:43, Pinpon_112 a dit :

Autre question, le tuto est pratique lorsqu'on est chez OVH.  J'envisage de migrer vers Infomaniak.  Que dois-je faire comme modification pour le certificat ?

Voir la doc : https://github.com/acmesh-official/acme.sh/wiki/dnsapi#119-use-infomaniakcom-api

Merci, je vais y jeter un gros coup d'oeil en espérant que ce ne soit pas trop compliqué à implémenter.

Posté(e)

Bonjour,

Il y a 2 heures, Pinpon_112 a dit :

Si je te comprend bien alors, je dois juste enlever '--force' et cela reviendra à la normale ?

Oui 😉

 

 

Posté(e)

@.shad

Merci, j'ai supprimé --set-defaut-ca et laissé --server letsencryp

Le script va plus loin mais me dit désormais :

[Sat Aug  6 13:11:12 CEST 2022] You don't specify OVH application key and application secret yet.
[Sat Aug  6 13:11:12 CEST 2022] Please create you key and try again.

Alors que j'ai bien fait au préalable :

$ export OVH_END_POINT=ovh-eu
$ export OVH_AK="votre application key"
$ export OVH_AS="votre application secret"
$ export OVH_CK="votre consumer key"

Avec mes valeurs de clé. On est d'accord qu'i ne faut pas mettre de " ?

 

 

Posté(e) (modifié)

@Pinpon_112 La question c'est surtout pourquoi tu as le paramètre force dans ton script.

@Tex5 Ca ça devrait fonctionner normalement, essaie de reprendre le tutoriel en amont. Non les guillemets sont à utiliser s'il y a des caractères spéciaux qui ont une fonctionnalité, un espace, un slash, etc... de souvenir les credentials OVH sont juste des chaînes de caractère de base. Mais les mettre n'empêche pas le bon fonctionnement.

Modifié par .Shad.
Posté(e)
Il y a 2 heures, .Shad. a dit :

La question c'est surtout pourquoi tu as le paramètre force dans ton script.

A vrai dire, je n'en sais rien.  En fait, lorsque je suis passé en DSM 7, j'ai cherché la version adaptée à mettre et c'est celle que j'ai trouvé sans vraiment faire attention au force.

@.Shad., concernant Infomaniak, si j'ai bien compris, dans le script, je vire tout ce qui concerne OVH et je remplace simplement par le token de Infomaniak ?

  • 1 mois après...
Posté(e)

Bonjour @.Shad.
 

Le 06/08/2022 à 07:13, .Shad. a dit :

Généralement ce genre d'erreur est lié à un problème de token, est-ce que par hasard tu n'aurais pas mis une durée d'un an sur celui-ci et que du coup logiquement il n'est plus actif ?

Qu'entends-tu par "token"?

Aujourd'hui, mon problème est toujours d'actualité...

Si je tente de renouveler mon certificat via le planificateur de tâches DSM (que ce soit en mode programmé ou mode forcé), j'ai systématiquement le droit à un message d'erreur:
 Add txt record error.
Error add txt for domain:_acme-challenge.XXXXX.NDD

Par contre, si je fais le renouvellement, manuellement, depuis l'invite de commande de WINSCP, ça passe...


Une explication?

Comment corriger le problème qui empêche le renouvellement depuis la planificateur de tâches de DSM (mode automatique et manuel/forcé)?

Merci.

Posté(e)

Le token c'est l'accès à l'API que tu as dû créer au début du tutoriel.
Mais si ça fonctionne d'une façon ou l'autre, ce n'est pas la cause, sinon ça ne marcherait pas quelque soit la méthode utilisée.

A quoi ressemble ta tâche DSM ?

Posté(e)

Bonjour @oracle7 et @.Shad.,

J'essaye d'implanter le certificat avec Infomaniak au lieu de OVH.

Actuellement, j'ai suivi tout le tuto jusqu'à devoir créer la partie d'Infomaniak.

Voilà ce que j'ai fait :

root@Seb_and_co:/usr/local/share/acme.sh# export INFOMANIAK_API_TOKEN=*************************token**********************
root@Seb_and_co:/usr/local/share/acme.sh# cd $ACME_HOME
root@Seb_and_co:/usr/local/share/acme.sh# export CERT_DOMAIN="ndd.tld"
root@Seb_and_co:/usr/local/share/acme.sh# export CERT_WDOMAIN="*.ndd.tld"
root@Seb_and_co:/usr/local/share/acme.sh# export CERT_DNS="dns_infomaniak"
root@Seb_and_co:/usr/local/share/acme.sh# ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt
[Sun Oct  9 11:33:44 CEST 2022] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory
root@Seb_and_co:/usr/local/share/acme.sh# 

Malheureusement, cela s'est arrêté là.  Pas de créations de certificat.

Une idée pour m'aider à avancer ?

Merci beaucoup

Posté(e)

Bonjour,

@Pinpon_112

As-tu essayé d'exporter ton token entre guillemets càd :

export INFOMANIAK_API_TOKEN="*************************token**********************"

@Tex5

Le 06/08/2022 à 13:20, Tex5 a dit :

Avec mes valeurs de clé. On est d'accord qu'i ne faut pas mettre de " ?

Bah NON, il faut justement mettre les guillemets. Regardes bien les commandes que j'ai indiqué dans le TUTO.

@Stixen92

Le 05/10/2022 à 03:25, Stixen92 a dit :

j'ai systématiquement le droit à un message d'erreur:
 Add txt record error.
Error add txt for domain:_acme-challenge.XXXXX.NDD

Peux-tu vérifier que :

  • la variable d'environnement DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' est bien définie dans le fichier account.conf (/usr/local/share/acme.sh/account.conf).
  • il n'y a pas (plus) dans ta zone DNS chez OVH d'enregistrements TXT du type " _acme-challenge.ndd.tld ". Si Oui supprimes le(s). Ils sont normalement créés et supprimés par acme.sh mais restent en cas d'erreurs.

Cordialement

oracle7😉

Posté(e) (modifié)

Bonjour @oracle7,

Citation

As-tu essayé d'exporter ton token entre guillemets càd :

export INFOMANIAK_API_TOKEN="*************************token**********************"

Je ne l'avais pas fait.  Je viens de refaire toutes la séquence à partir du token en le mettant entre "" cette fois et au final, c'est la même chose que la première fois.

Voici ce qui est dit sur le Github pour Infomaniak :

Citation

Infomaniak hosts a large number of domains and other hosted services. Create a token with Domain scope in the API dashboard at https://manager.infomaniak.com/v3/<account_id>/api/dashboard and export it as an environment variable:

export INFOMANIAK_API_TOKEN=xxx
./acme.sh --issue --dns dns_infomaniak -d example.com -d www.example.com

 

Modifié par Pinpon_112
Posté(e)

Bonjour @oracle7,

Bonne nouvelle, j'avance.  J'ai réussi à créer mon certificat.

Par contre, j'ai un problème pour déployer ce dernier.  Un petit coup de main ?

J'ai continué ta procédure et voilà ce que j'ai dans le terminal :

root@dsm:/usr/local/share/acme.sh# export SYNO_Scheme="http"
root@dsm:/usr/local/share/acme.sh# export SYNO_Hostname="localhost"
root@dsm:/usr/local/share/acme.sh# export SYNO_Port="5000"
root@dsm:/usr/local/share/acme.sh# export SYNO_Username='username'
root@dsm:/usr/local/share/acme.sh# export SYNO_Password='pswd'
root@dsm:/usr/local/share/acme.sh# export SYNO_Certificate=""
root@dsm:/usr/local/share/acme.sh# ./acme.sh --deploy -d "ndd.tld" --deploy-hook synology_dsm
[Mon Oct 10 17:25:43 CEST 2022] Logging into localhost:5000
[Mon Oct 10 17:25:48 CEST 2022] Unable to authenticate to localhost:5000 using http.
[Mon Oct 10 17:25:48 CEST 2022] Check your username and password.
[Mon Oct 10 17:25:48 CEST 2022] Error deploy for domain:ndd.tld
[Mon Oct 10 17:25:48 CEST 2022] Deploy error.

Un petit coup de pouce ?

Pour info, avec Infomaniak, toute la partie avec OVH n'est pas à faire.  J'ai créé le certificat avec cette commande

./acme.sh --issue --keylength 4096 --dns dns_infomaniak -d ndd.tld -d *.ndd.tld

après avoir exporté le token Infomaniak sans les ".

Posté(e)

@Pinpon_112

Bonjour,

il y a une heure, Pinpon_112 a dit :
[Mon Oct 10 17:25:48 CEST 2022] Check your username and password.

Le message est clair non ? Soit ton username, soit ton password comportent des caractères spéciaux qui bloquent le procéssus. Je ne vois que cela ...

On croit généralement bien faire en ajoutant des caractères spéciaux à ses identifiants/mots de passe et certes humainement cela semble plus difficile à lire(et à se souvenir) mais informatiquement parlant cela n'amène aucune complexité supplémentaire mais plutôt des problèmes car souvent ces caractères spéciaux sont des caractères réservés du système d'exploitation et du coup les interpréteurs de commandes s'y perdent. De plus cryptographiquement parlant un caractère dit spécial n'apporte qu'un bit supplémentaire alors qu'ajouter tout simplement un caractère standard (majuscule ou minuscule ou chiffre) en apporte onze, ce qui rallonge drastiquement le temps de déchiffrement pour un malveillant.

Moralité, sous UNIX/Linux donc DSM/SRM, les identifiants et surtout les mots de passe, pour être efficaces doivent être très long (au moins > 12 caractères avec que des majuscules ou minuscules ou chiffres). Maintenant ce que j'en dis ...

A part cela, pourquoi ta variable SYNO_Certificate est-elle vide/non renseignée ?

Cordialement

oracle7😉

 

Posté(e)

Bonjour @oracle7,

Citation

Le message est clair non ? Soit ton username, soit ton password comportent des caractères spéciaux qui bloquent le procéssus. Je ne vois que cela ...

Depuis que je suis le processus de ton tuto, j'ai appris cela et je n'ai que des minuscules, majuscules et chiffres dans mon mot de passe.  Pour mon username, il y a juste un _ mais cela fonctionnait avant.

Citation

A part cela, pourquoi ta variable SYNO_Certificate est-elle vide/non renseignée ?

Parce que dans le tuto, point 5.2.1, tu dis qu'elle doit être vide.

Ceci dit, j'ai aussi essayé avec le 5.2.2, donc en renseignant un nom mais c'est la même chose.  Problème de username/password.

Posté(e)

@Pinpon_112

Bonjour,

Autres questions pour essayer de cerner le problème :

  • Les ports 5000 et 5001 sont-ils bien ouverts/autorisés dans le pare-feu du NAS ?
  • Est-ce que tu utilises la 2FA pour ton utilisateur courant ? Car si tu utilises la 2FA, saches que acme a récemment modifié le script de déploiement synology_dsm.sh. Celui-ci impose l'usage de la clé secrète de la 2FA au travers d'une variable d'environnement SYNO_TOTP_SECRET. Sauf que le script python ne gère pas cette nouvelle variable. Du coup, le déploiement du certificat ne se fait plus automatiquement. Cela ne bloque pas la création du certificat mais juste le déploiement. Il faut alors installer sur le NAS un outil tiers oathtool selon la procédure décrite ici .

De toutes façons comme tout se passe en local, il est préférable de créer un utilisateur (type admin) dédié pour gérer le certificat et son renouvellement, qui n'a pas la 2FA d'activée. Et cela résoud le problème aussi.

Cordialement

oracle7😉

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.