Aller au contenu

Messages recommandés

Posté(e) (modifié)
Le 30/05/2020 à 10:35, oracle7 a dit :

$ cd $ACME_HOME

$ export CERT_DOMAIN="votre-domaine.tld"
$ export CERT_WDOMAIN="*.votre-domaine.tld"
$ export CERT_DNS="dns_ovh"
$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt

Edit du 20/06/2021 :

Suite aux récentes évolutions du Shell script ACME la commande de création du certificat doit être complétée par deux options. En effet, dorénavant lors de la création d'un nouveau certificat, par défaut c'est un certificat ZeroSSL qui est créé par ACME. Donc dans notre cas, comme l'on veux générer un certificat LesEncrypt, on doit ajouter les options suivantes à la commande de création pour forcer la génération du certificat LE :

--set-default-ca --server letsencryp

ainsi le shell script ACME prendra en compte ce choix qu'il retiendra d'ailleurs par la suite lors du renouvellement du certificat.

Merci @oracle7 pour la maintenance.

J'ai "bêtement" ouvert mon SSH et tappé ces lignes de commande mais j'obtiens un message d'erreur ...

 

/volume1/Scripts$ cd $ACME_HOME
/root$ export CERT_DOMAIN="ndd.tld"
/root$ export CERT_WDOMAIN="*.ndd.tld"
/root$ export CERT_DNS="dns_ovh"
/root$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt
-ash: line 81: ./acme.sh: No such file or directory
/root$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencryp
-ash: line 83: ./acme.sh: No such file or directory


Pourrais tu stp m'aider ?

J'ai même un problème pout lire le fichier acmelog : un message d'erreur m'i,dique que le fichier ne peut être créé avec le message suivant :

Erreur système. Code : 123.
La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte

Cordialement,

Modifié par TuringFan
Posté(e)

@TuringFan

Bonjour,

  1. Avant de taper ces commandes, avais-tu aussi exportée la variable ACME_HOME, je serais tenté de dire non vu le message d'erreur qui te dit que "./acme.sh: No such file or directory". Tu n'étais pas a priori dans le bon répertoire pour lancer la commande vu qu'il n'a pas trouvé le script acme.sh.
    Donc il te faut faire en préalable :
    export ACME_HOME="/usr/local/share/acme.sh"
    puis
    cd $ACME_HOME
  2. Comme je suppose (mais je me trompe peut-être) que tu recrées un certificat LE mais que tu avais déjà une installation de acme.sh existante, alors vérifies aussi que tu n'as pas déjà la variable d'environnement :

    DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'

    de définie dans le fichier account.conf (/usr/local/share/acme.sh/account.conf).
    Si c'est le cas, alors il n'est pas utile d'ajouter les options " --set-default-ca --server letsencrypt " dans la commande " $ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" ". C'est uniquement valable lorsque l'on part complétement de zéro pour créer le certificat LE.

Cordialement

oracle7😉

Posté(e)

Merci @oracle7,

Pour le point 2 j'ai effectivement la ligne sur le defaut_acme-server sur mon fichier account.

Voici ce que je tape :

/volume1/Certs/Acme_renew$ cd $ACME_HOME
/usr/local/share/acme.sh$ export CERT_DOMAIN="ndd.tld"
/usr/local/share/acme.sh$ export CERT_WDOMAIN="*.ndd.tld"
/usr/local/share/acme.sh$ export CERT_DNS="dns_ovh"
/usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"

Voici mon output

[Sun Dec 12 21:19:46 CET 2021] Using CA: https://acme.zerossl.com/v2/DV90
[Sun Dec 12 21:19:46 CET 2021] Create account key ok.
[Sun Dec 12 21:19:46 CET 2021] No EAB credentials found for ZeroSSL, let's get one
[Sun Dec 12 21:19:46 CET 2021] acme.sh is using ZeroSSL as default CA now.
[Sun Dec 12 21:19:46 CET 2021] Please update your account with an email address first.
[Sun Dec 12 21:19:46 CET 2021] Please add '--debug' or '--log' to check more details.
[Sun Dec 12 21:19:46 CET 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
[Sun Dec 12 21:19:46 CET 2021] acme.sh --register-account -m my@example.com
[Sun Dec 12 21:19:46 CET 2021] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA

Où dois je m'inscrire ?

Pas certain de suivre ce point.

Merci d'avance as usual,

Posté(e)

@TuringFan

Bonjour,

C'est étonnant, normalement comme tu avais déjà la variable DEFAULT_ACME_SERVER de définie dans account.conf, il n'aurait pas dû passer par ZeroSSL. Bizarre, bizarre ...🧐

Ré-essaies, cette fois en ajoutant les deux options " --set-default-ca --server letsencrypt ".

Cordialement

oracle7😉

Posté(e) (modifié)

@oracle7,

Je viens de taper 

ACME_HOME="/usr/local/share/acme.sh"
cd $ACME_HOME
export CERT_DOMAIN="ndd.tld"
export CERT_WDOMAIN="*.ndd.tld"
export CERT_DNS="dns_ovh"
./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt

J'obtiens alors 

[Sun Dec 12 23:14:16 CET 2021] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory

Je tape ensuite

cd / volume1/Scripts
python acme_renew.py -f ndd.tld

J'obtiens un log qui termine par 

--- Le certificat n'a pas ete renouvele.
--- => Consulter le log : /volume1/Certs/Acme_renew/acmelog

Puis quand je vais ouvrir le fichier acmelog un message d'erreur m'indique que le fichier acmelog ne peut par être créé et il est précisé :

Erreur système. Code : 123.
La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte

Que puis je faire ?

A noter que j'ai essayé de renouveler le certificat en passant par le DSM mais en demandant un certificat pour "*.ndd.tld" un message d'erreur m'indique que les certificats génériques ne fonctionnent que pour les DDNS Synology.

Preneur de tes lumières, je sèche ...

PS : évidemment j'ai bien remplacé les "ndd.tld" par mon propre domaine à chaque fois.

Modifié par TuringFan
Posté(e)

@TuringFan

Bonjour,

Je ne comprends pas :

  • d'un coté en premier lieu tu crées le certificat. il te répond d'ailleurs qu'il a bien créé un certificat LE et pas ZéroSSL.
  • d'un autre coté ensuite tu cherches à le renouveler ??? Pourquoi ??? attends au moins le moment venu (dans 2 mois minimum) mais normalement c'est la tâche DSM qui s'en occupe automatiquement en laçant la commande de renouvellement via le script python ...

Au final, tu as bien tes fichiers de certificats dans /volume1/Certs/tondomaine.tld, O/N ?


Attention, si tu es passé sous DSM7 le script python n'est plus utile. La tâche à lancer dans le planificateur DSM est simplement celle-ci (comme à l'origine du TUTO v1.0) :

bash /usr/local/share/acme.sh/acme.sh --cron --force --debug --home /usr/local/share/acme.sh/
Il y a 15 heures, TuringFan a dit :

Puis quand je vais ouvrir le fichier acmelog un message d'erreur m'indique que le fichier acmelog ne peut par être créé et il est précisé :

Erreur système. Code : 123.
La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte

Le message me paraît clair, tu as dû faire une faute de frappe ou bien le fichier acmelog n'existe pas dans le répertoire.

Par où passes-tu pour l'ouvrir ? quelle commande tu tapes ?

Il y a 15 heures, TuringFan a dit :

A noter que j'ai essayé de renouveler le certificat en passant par le DSM mais en demandant un certificat pour "*.ndd.tld" un message d'erreur m'indique que les certificats génériques ne fonctionnent que pour les DDNS Synology.

Cà c'est normal que DSM te réponde cela, c'est bien pour cela que la présente méthode a été mise en place pour pouvoir créer un certificat "wilcard" pour un domaine de type "ndd.tld" vu que DSM ne le permet pas, alors pourquoi veux-tu quand même le faire via DSM ? Il me semblait que c'était clairement dit dans le TUTO.

Cordialement

oracle7😉


 

Posté(e)
il y a une heure, oracle7 a dit :

e ne comprends pas :

  • d'un coté en premier lieu tu crées le certificat. il te répond d'ailleurs qu'il a bien créé un certificat LE et pas ZéroSSL.
  • d'un autre coté ensuite tu cherches à le renouveler ??? Pourquoi ??? attends au moins le moment venu (dans 2 mois minimum) mais normalement c'est la tâche DSM qui s'en occupe automatiquement en laçant la commande de renouvellement via le script python ...

En fait ma première manip me sert à faire un "reset" pour partir d'une base propre avec des certificats qui tournent.
Ensuite je force le renouvellement (pour anticiper ce qui se passera dans 3 mois) et pour vérifier que le process tourne correctement.

In fine indépendamment des logs le certificat reste inchangé sur l'interface DSM ...

Il y a 1 heure, oracle7 a dit :

Attention, si tu es passé sous DSM7 le script python n'est plus utile. La tâche à lancer dans le planificateur DSM est simplement celle-ci (comme à l'origine du TUTO v1.0) :

Non pas encore passé sur DSM 7.0 : preneur d'ailleurs d'un lien pour les bonnes pratiques / pièges à éviter.

Il y a 1 heure, oracle7 a dit :

Le message me paraît clair, tu as dû faire une faute de frappe ou bien le fichier acmelog n'existe pas dans le répertoire.

Par où passes-tu pour l'ouvrir ? quelle commande tu tapes ?

Je me mets dans WinSCP en l'utilisant comme explorateur pour directement ouvrir le fichier que je vois bien dans le répertoire : c'est lors de l'ouverture que j'ai le message d'erreur. Comme ci le fichier était une coquille vide ...

Il y a 1 heure, oracle7 a dit :

Cà c'est normal que DSM te réponde cela, c'est bien pour cela que la présente méthode a été mise en place pour pouvoir créer un certificat "wilcard" pour un domaine de type "ndd.tld" vu que DSM ne le permet pas, alors pourquoi veux-tu quand même le faire via DSM ? Il me semblait que c'était clairement dit dans le TUTO.

Oui, aucune ambiguïté la dessus : je voulais voir si j'avais un message d'erreur "exotique" ou si cela se comportait "comme avant".

Cordialement,

Posté(e)

@oracle7,

Je viens d'essayer de recréer un certificat avec le code tappé sous WinSCP

 

/root$ ACME_HOME="/usr/local/share/acme.sh"
/root$ cd $ACME_HOME
/usr/local/share/acme.sh$ export CERT_DOMAIN="ndd.tld"
/usr/local/share/acme.sh$ export CERT_WDOMAIN="*.ndd.tld"
/usr/local/share/acme.sh$ export CERT_DNS="dns_ovh"
/usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"

J'obtiens ensuite le log 

[Mon Dec 13 23:08:52 CET 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Mon Dec 13 23:08:53 CET 2021] Create account key ok.
[Mon Dec 13 23:08:53 CET 2021] Registering account: https://acme-v02.api.letsencrypt.org/directory
[Mon Dec 13 23:08:54 CET 2021] Registered
[Mon Dec 13 23:08:54 CET 2021] ACCOUNT_THUMBPRINT='***'
[Mon Dec 13 23:08:54 CET 2021] Creating domain key
[Mon Dec 13 23:08:57 CET 2021] The domain key is here: /root/.acme.sh/ndd.tld/ndd.tld
[Mon Dec 13 23:08:57 CET 2021] Multi domain='DNS:ndd.tld,DNS:*.ndd.tld'
[Mon Dec 13 23:08:57 CET 2021] Getting domain auth token for each domain
[Mon Dec 13 23:08:59 CET 2021] Getting webroot for domain='ndd.tld'
[Mon Dec 13 23:09:00 CET 2021] You don't specify OVH application key and application secret yet.
[Mon Dec 13 23:09:00 CET 2021] Please create you key and try again.
[Mon Dec 13 23:09:00 CET 2021] Getting webroot for domain='*.ndd.tld'
[Mon Dec 13 23:09:00 CET 2021] Adding txt value: *** for domain:  _acme-challenge.ndd.tld
[Mon Dec 13 23:09:00 CET 2021] Error add txt for domain:_acme-challenge.ndd.tld
[Mon Dec 13 23:09:00 CET 2021] Please add '--debug' or '--log' to check more details.
[Mon Dec 13 23:09:00 CET 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

Vois tu le problème ?

Posté(e)

En passant par PuTTY même les logs semblent bizarres 

[Mon Dec 13 23:35:43 CET 2021] ===Starting cron===
[Mon Dec 13 23:35:43 CET 2021] Using config home:/usr/local/share/acme.sh/
[Mon Dec 13 23:35:43 CET 2021] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.                                                                                        'rg/directory
[Mon Dec 13 23:35:43 CET 2021] _stopRenewOnError
[Mon Dec 13 23:35:43 CET 2021] _set_level='2'
/*.*/'ec 13 23:35:43 CET 2021] di='/volume1/Certs
/*.*/Dec 13 23:35:43 CET 2021] Not a directory, skip: /volume1/Certs
[Mon Dec 13 23:35:43 CET 2021] _error_level='3'
[Mon Dec 13 23:35:43 CET 2021] _set_level='2'
[Mon Dec 13 23:35:43 CET 2021] ===End cron===

 

Posté(e)

@TuringFan

Bonjour,

Il y a 14 heures, TuringFan a dit :
[Mon Dec 13 23:09:00 CET 2021] You don't specify OVH application key and application secret yet.
[Mon Dec 13 23:09:00 CET 2021] Please create you key and try again.

Bah, le problème est là, le message est clair, non ?

Au passage, quand tu crées un certificat, dans des manipulations, surtout si tu relances un processus interrompu précédemment sur erreur ou que (surtout lorsque) tu repars dans une nouvelle session SSH, il faut penser à redéclarer/exporter TOUTES les variables d'environnement, logique non ?. Sinon tu auras des problèmes. Après le contenu des logs n'est que la conséquences de ces erreurs.

Dans le cas présent, la session n'a pas dû trouvé en mémoire les variables OVH_AK, OVH_AS et OVH_CK, c'est du moins ce que je subodore.

Attention au nombre de tentatives de création/renouvellement : 5 MAXI par semaine sinon tu seras bloqué au delà.

Cordialement

oracle7😉

Posté(e)

@oracle7 merci pour ton aide.

Je n'avais jamais eu à redéclarer / exporter ces variables, j'ai donc appliqué tes conseils.

J'ai tappé

/volume1$ cd /volume1
/volume1$ cd Certs/Acme_install
/volume1/Certs/Acme_install$ ACME_HOME="/usr/local/share/acme.sh"
/volume1/Certs/Acme_install$ CERT_HOME="/volume1/Certs"
/volume1/Certs/Acme_install$ cd $CERT_HOME
/volume1/Certs$ export OVH_END_POINT=ovh-eu
/volume1/Certs$ export OVH_AK="***"
/volume1/Certs$ export OVH_AS="***"
/volume1/Certs$ export OVH_CK="***"
/volume1/Certs$ cd $ACME_HOME
/usr/local/share/acme.sh$ export CERT_DOMAIN="ndd.tld"
/usr/local/share/acme.sh$ export CERT_WDOMAIN="*.ndd.tld"
/usr/local/share/acme.sh$ export CERT_DNS="dns_ovh"
/usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"
[Tue Dec 14 22:33:21 CET 2021] Domains not changed.
[Tue Dec 14 22:33:21 CET 2021] Skip, Next renewal time is: Sat Feb 12 21:15:08 UTC 2022
[Tue Dec 14 22:33:21 CET 2021] Add '--force' to force to renew.
/usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --force

Et j'obtiens
 

[Tue Dec 14 22:34:15 CET 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Tue Dec 14 22:34:16 CET 2021] Multi domain='DNS:ndd.tld,DNS:*.ndd.tld'
[Tue Dec 14 22:34:16 CET 2021] Getting domain auth token for each domain
[Tue Dec 14 22:34:19 CET 2021] Getting webroot for domain='ndd.tld'
[Tue Dec 14 22:34:19 CET 2021] Getting webroot for domain='*.ndd.tld'
[Tue Dec 14 22:34:19 CET 2021] ndd.tld is already verified, skip dns-01.
[Tue Dec 14 22:34:19 CET 2021] *.ndd.tld is already verified, skip dns-01.
[Tue Dec 14 22:34:19 CET 2021] Verify finished, start to sign.
[Tue Dec 14 22:34:19 CET 2021] Lets finalize the order.
[Tue Dec 14 22:34:19 CET 2021] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/320043130/47314989630'
[Tue Dec 14 22:34:20 CET 2021] Downloading cert.
[Tue Dec 14 22:34:20 CET 2021] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/04dd41cf3ea49530f032b26a254546ac720f'
[Tue Dec 14 22:34:21 CET 2021] Cert success.
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
[Tue Dec 14 22:34:21 CET 2021] Your cert is in: /root/.acme.sh/ndd.tld/ndd.tld.cer
[Tue Dec 14 22:34:21 CET 2021] Your cert key is in: /root/.acme.sh/ndd.tld/ndd.tld.key
[Tue Dec 14 22:34:21 CET 2021] The intermediate CA cert is in: /root/.acme.sh/ndd.tld/ca.cer
[Tue Dec 14 22:34:21 CET 2021] And the full chain certs is there: /root/.acme.sh/ndd.tld/fullchain.cer

Bref ça à l'air de tourner en revanche je ne comprends pas pourquoi les certificats s'enregistrent dans /root/.acme.sh et non pas dans volume1/Certs ?

Car du coup dans l'interface DSM mon certificat ne semble pas remonter et je vois toujours l'ancien. Comment faire ?

Merci d'avance,

Posté(e) (modifié)

@TuringFan Bonjour,

Il est possible que le problème vienne de là:

Il y a 17 heures, oracle7 a dit :

Au passage, quand tu crées un certificat, dans des manipulations, surtout si tu relances un processus interrompu précédemment sur erreur ou que (surtout lorsque) tu repars dans une nouvelle session SSH, il faut penser à redéclarer/exporter TOUTES les variables d'environnement, logique non ?.

Acme a interrompu le script car la date de renouvellement enregistrée sur ton nas n'est pas encore dépassée (sans doute du fait de tes essais précédents). Il a donc été suggéré de forcer le renouvellement et je suppose que la variable CERT_HOME a perdu sa valeur du fait de cette interruption.

Le mieux pour toi c'est d'attendre le retour d' @oracle7 car il va falloir faire un peu de ménage avant de recommencer et effectivement les tentatives de renouvellement sont comptées pour cette semaine.

Maintenant ton certificat existe, au pire il sera donc possible de l'utiliser en le mettant au bon endroit.

 

 

 

 

Modifié par Jeff777
Posté(e)

@TuringFan

Si ton certificat a été généré dans "/root/.acme.sh", c'est que tu as très certainement réinstallé le script acme.sh sans préciser l'option "--cert-home" (voir §2 du TUTO) et même si ensuite tu as déclarée la variable CERT_HOME sur "/volume1/Certs", si je ne dis pas de bêtise, c'est alors normal qu'elle ne soit pas prise en compte par le script.
Cela dit, tu as quand même tes fichiers de certificat qui ont été correctement générés. Tu peux donc les reprendre pour les injecter dans DSM sans soucis, cela marchera et tu seras couvert.

@Jeff777 a raison, si tu veux disposer de quelque chose de propre pour que le renouvellement se fasse sans encombre plus tard, il te faudra faire du ménage (réinstaller correctement acme.sh entre autres).

Cordialement

oracle7😉

Posté(e)
Il y a 1 heure, oracle7 a dit :

il te faudra faire du ménage (réinstaller correctement acme.sh entre autres).

Merci @oracle7 et @Jeff777,

Pour faire les choses correctement cette fois-ci comment dois-je m'y prendre ?

  1. Désinstaller acme.sh : si oui comment faire ?
  2. Supprimer les fichiers : si oui lesquels ?§
  3. Reprende le tuto sur les parties 2, 4 et 5 ?

Ai-je oublié quelque chose ?

Posté(e)

@TuringFan

Bonjour,

Normalement si tu as bien suivi initialement le TUTO tu avais extrait tous les fichiers du script acme.sh dans le répertoire : /volume1/Certs/Acme_install. Dans ce répertoire tu dois avoir encore un dossier "acme.sh-master".

Tu tapes sous root dans un terminal SSH :

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

# ./acme.sh --uninstall

Cela devrait supprimer entièrement le script acme.sh et ses fichiers. Normalement dans /usr/local/share tu ne devrais plus avoir de répertoire acme.sh sinon tu le supprimes :

# cd /usr/local/share

# ls -al

si besoin

# rm -rf acme.sh

Ensuite tu reprends le TUTO à partir du §2. Tu ne recrées tes clés OVH (§3.1) que si c'est un nouveau domaine  (i.e. différent de l'ancien) sinon tu récupères celles que tu avais sauvegardées précédemment.

Avec un peu beaucoup d'attention et de rigueur, cela devrait le faire ...🤪

Cordialement

oracle7😉

Posté(e)

Merci beaucoup @oracle7 pour ta pédagogie.

J'ai suivi tes instructions de désinstallation de acme puis j'ai redescendu le tuto pas à pas.

Voici en gros ce que j'ai fait ce que j'ai fait

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

PS j'ai essayé avec 

  • export SYNO_Scheme="https"
  • export SYNO_Hostname="localhost"
  • export SYNO_Port="5001"

Mais j'avais un problème que j'aavis également eu la première fois de mémoire, je suis donc parti sur http /5000

Premiers éléments à noter

J'ai obtenu un log SSH avec à la fin :

[Fri Dec 17 20:06:14 CET 2021] Logging into localhost:5000
[Fri Dec 17 20:06:15 CET 2021] Getting certificates in Synology DSM
[Fri Dec 17 20:06:15 CET 2021] Generate form POST request
[Fri Dec 17 20:06:15 CET 2021] Upload certificate to the Synology DSM
[Fri Dec 17 20:06:16 CET 2021] http services were NOT restarted
[Fri Dec 17 20:06:16 CET 2021] Success

Bon signe donc.

Dans l'interface DSM je voyais bien un certificat ACME mais 

  1. la date de préremption était inférieure au certificat créé à la main il y quelques jours
  2. le certificat n'apparait par comme certificat par défaut
  3. mon navigateur indiquait toujours mon ancien certificat après (i) configuration du certificat ACME par défaut, (ii) suppression de mon ancien certificat dans le DSM et (iii) déconnexion/reconnexion au DSM

Pour pousser l'exercice jusqu'au bout j'ai forcé un renouvellement

cd /volume1
cd /volume1/Scripts
/volume1/Scripts$ python acme_renew.py -f ndd.tld

J'ai alors obtenu un log bien plus long que d'habitude dans l'exécution avec de nombreuses itérations de code du type GET / Retrying GET (cf. exemple ci-dessous).
 

GET
[Fri Dec 17 20:29:55 CET 2021] url='https://eu.api.ovh.com/1.0/auth/time'
[Fri Dec 17 20:29:55 CET 2021] timeout=30
[Fri Dec 17 20:29:55 CET 2021] displayError='1'
[Fri Dec 17 20:29:55 CET 2021] _CURL='curl --silent --dump-header /usr/local/share/acme.sh//http.header  -L  -g  --connect-timeout 30'
[Fri Dec 17 20:29:55 CET 2021] ret='0'
[Fri Dec 17 20:29:55 CET 2021] _hcode='0'
[Fri Dec 17 20:29:55 CET 2021] _ovh_p='[hidden](please add '--output-insecure' to see this value)'
Retrying GET

In fine j'ai eu en fin de log 

[Fri Dec 17 20:30:23 CET 2021] Your cert is in: /volume1/Certs/ndd.tld/ndd.tld.cer
[Fri Dec 17 20:30:23 CET 2021] Your cert key is in: /volume1/Certs/ndd.tld/ndd.tld.key
[Fri Dec 17 20:30:23 CET 2021] The intermediate CA cert is in: /volume1/Certs/ndd.tld/ca.cer
[Fri Dec 17 20:30:23 CET 2021] And the full chain certs is there: /volume1/Certs/ndd.tld/fullchain.cer

...
 

-- Renouvellement certificat via acme.sh
  -- commande acme.sh : bash /usr/local/share/acme.sh/acme.sh --cron --force --debug --home /usr/local/share/acme.sh/

-- Nouveau certificat par DEFAULT : TIucVw
--- Le certificat n'a pas ete renouvele.
--- => Consulter le log : /volume1/Certs/Acme_renew/acmelog

Situation actuelle
 

J'ai ensuite récupéré le certificat pour l'importer sur mon routeur.

  • J'ai maintenant le même certificat sur mon NAS et mon routeur et mon navigateur indique qu'ils sont valides du 1712/2021 jusqu'au 18/03/2022 et qu'ils sont délivrés par ZeroSSL
  • Enfin mes certificats sont bien maintennat dans Volume1/certs/ndd.tld et tous les fichiers sont en date du 17/12/2021 sauf le clé de RSA mais je comprends que c'est normal ?

A noter également que mon certificat intermédiaire n'a plus la première ligne vide à faire sauter et qu'il semble concaténer deux certificats avec un format du type :

-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----

Bref ça semble fonctionner mais sans vraiment comprendre ce qui s'est passé ...

Dernière question

Enfin @oracle7 je comprends que suite aux récentes évolutions du Shel script ACME je peux complètement supprimer la tache planifiée ? Je n'aurai juste donc qu'a importer tous les 3 mois le certificat (automatiquement renouvelé) de mon NAS vers mon routeur. Quid du DID dans tous ça ?

Merci d'avance

Posté(e)

@TuringFan

Bonjour,

il y a 7 minutes, TuringFan a dit :

Mais j'avais un problème que j'aavis également eu la première fois de mémoire, je suis donc parti sur http /5000

Tu as bien fait car il est inutile de faire du HTTPS sur le réseau local à moins que tu ais des "espions en herbes". Sinon il suffisait de rajouter l'option "--insecure" dans la commande de déploiement.

il y a 8 minutes, TuringFan a dit :
  • la date de préremption était inférieure au certificat créé à la main il y quelques jours
  • le certificat n'apparait par comme certificat par défaut
  • mon navigateur indiquait toujours mon ancien certificat après (i) configuration du certificat ACME par défaut, (ii) suppression de mon ancien certificat dans le DSM et (iii) déconnexion/reconnexion au DSM
  • Point 1 : ????? Étonnant mais pourquoi pas ...
  • Point 2 : Tu n'avais pas déjà un certificat marqué par défaut ?, auquel cas ce qui expliquerait cela.
  • Point 3 : Sauf erreur de ma part, il faut en plus vider le cache du navigateur Web et relancer une connexion au NAS pour que le navigateur prenne en compte le nouveau certificat sinon il garde en "mémoire" l'ancien certificat, ce qui t'est arrivé.
il y a 12 minutes, TuringFan a dit :
--- Le certificat n'a pas ete renouvele.
--- => Consulter le log : /volume1/Certs/Acme_renew/acmelog

Dans ce cas de figure précis, c'est un "bug" connu qui a été identifié en son temps mais comme ce n'est pas bloquant, on est resté avec.

il y a 15 minutes, TuringFan a dit :

qu'ils sont délivrés par ZeroSSL

Là dans la commande de création du certificat tu n'as pas dû (oublié de 🤪) ajouter les deux options :

--set-default-ca --server letsencryp

Vérifies aussi que tu as bien dans ton fichier "account.conf" (/usr/local/share/acme.sh/account.conf) la variable :

DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'

Sinon ajoutes-la à la fin du fichier et en principe au prochain renouvellement tu devrais avoir un certificat LE et pas ZéroSSL.

il y a 21 minutes, TuringFan a dit :

je comprends que suite aux récentes évolutions du Shel script ACME je peux complètement supprimer la tache planifiée ?

NON pas du tout, si tu es en DSM6 tu conserves la tâche avec le script python (cf TUTO) et si tu es sous DSM7 le script python n'est plus utile donc tu remplaces par la tâche suivante :

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

Cordialement

oracle7😉

 

 

 

Posté(e)
il y a 21 minutes, oracle7 a dit :

Tu as bien fait car il est inutile de faire du HTTPS sur le réseau local à moins que tu ais des "espions en herbes". Sinon il suffisait de rajouter l'option "--insecure" dans la commande de déploiement.

ok

il y a 22 minutes, oracle7 a dit :

Point 2 : Tu n'avais pas déjà un certificat marqué par défaut ?, auquel cas ce qui expliquerait cela.

si mais je pensais que le process overwrittait cela
 

il y a 22 minutes, oracle7 a dit :

Point 3 : Sauf erreur de ma part, il faut en plus vider le cache du navigateur Web et relancer une connexion au NAS pour que le navigateur prenne en compte le nouveau certificat sinon il garde en "mémoire" l'ancien certificat, ce qui t'est arrivé.

ok

il y a 22 minutes, oracle7 a dit :

Dans ce cas de figure précis, c'est un "bug" connu qui a été identifié en son temps mais comme ce n'est pas bloquant, on est resté avec.

ok
 

il y a 23 minutes, oracle7 a dit :

Là dans la commande de création du certificat tu n'as pas dû (oublié de 🤪) ajouter les deux options :

--set-default-ca --server letsencryp

Je l'ai fait justement

il y a 24 minutes, oracle7 a dit :

Vérifies aussi que tu as bien dans ton fichier "account.conf" (/usr/local/share/acme.sh/account.conf) la variable :

DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'

Sinon ajoutes-la à la fin du fichier et en principe au prochain renouvellement tu devrais avoir un certificat LE et pas ZéroSSL.

Je l'ai bien

Est ce un problème d'avoir un certificat ZéroSSL ?

il y a 24 minutes, oracle7 a dit :

NON pas du tout, si tu es en DSM6 tu conserves la tâche avec le script python (cf TUTO) et si tu es sous DSM7 le script python n'est plus utile donc tu remplaces par la tâche suivante :

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

 

ok

Merci encore @oracle7

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

bonjour,

 

mon certificat est expiré et le script python ne fonctionne pas

 

il y a un timeout au niveau de CURL

 

9QPV1Gw.png

image.png.a3829980a96b25b0300031b10a6ba066.png

dans le fichier account j'ai bien

DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'

quand je tente un curl https://acme-v02.api.letsencrypt.org/directory

j'ai cette réponse


curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

 

 

merci de votre retour

 

 

 

Posté(e)

@romain1206

Bonjour,

Vu qu'acme.sh bute sur l'url " https://acme-v02.api.letsencrypt.org/directory ", je serais tenter de dire (mais sans garantie) que ce sont les serveurs de LE qui sont surchargés ou bien qu'il ne peut les atteindre du fait que le ports 80 et 443 ne sont pas ouverts dans ton pare-feu du NAS au moment du renouvellement.

Assures-toi aussi qu'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)

Merci pour tout ça marche nickel!

Je suis sous DSM 7 et au niveau de la tâche planifiée j'ai fait ce que tu as écrit dans la conversation, c'est à dire ne pas utiliser python et mettre direct:

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

 

Question:

J'ai 2 ndd à renouveler.
Les 2 sont chez OVH et les clés OVH que j'ai généré sont valables poru tous les ndd.

Je me suis dit qu'il suffisait que je crée 2 tâches planifiées qui ressembleront à ça:

export CERT_DOMAIN="votre-domaine.tld"
export CERT_WDOMAIN="*.votre-domaine.tld"
export SYNO_Certificate=""
bash /usr/local/share/acme.sh/acme.sh --cron --force --debug --home /usr/local/share/acme.sh/
export CERT_DOMAIN="votre-domaine2.tld"
export CERT_WDOMAIN="*.votre-domaine2.tld"
export SYNO_Certificate="Autre certif"
bash /usr/local/share/acme.sh/acme.sh --cron --force --debug --home /usr/local/share/acme.sh/

Mais le second certificat a le nom du premier donc mes "export" semblent pas suffisant.
Même si pourtant le second certificat a bien la description "Autre certif"...

Qu'en penses-tu?

Posté(e)

@Double Jo

Bonjour,

il y a 56 minutes, Double Jo a dit :

Mais le second certificat a le nom du premier donc mes "export" semblent pas suffisant.

Déjà, il n'y a pas besoin de faire d'export de variables d'environnement pour exécuter la tâche programmée. D'autre part, tu lancerais deux fois la même tâche programmée qui elle ne prend pas en compte le domaine contrairement au script python. Donc il y aurait un beau patacaisse en perspective 🤨

Donc pourquoi faire deux certificats (un par domaine) ? Tu pourrais aussi bien faire un seul certificat qui regrouperait les deux domaines et leur wilcard respectif.

De toutes façons, la présente méthode ne permet de créer qu'un et un seul certificat LE à la fois.

Si tu veux deux certificats distincts, pour bien faire il faudrait exécuter la méthode deux fois mais désolé je ne sais pas faire vis à vis du renouvellement sous DSM7 car la commande à mettre dans la tâche programmée ne prend pas en compte le domaine contrairement au script python. Tu me suis ? Sous DSM6 avec le script python, effectivement on pourrait lancer une tâche programmée par domaine.

D'où l'idée (j'y reviens) de faire sous DSM7 un certificat pour les deux domaines.

Cordialement

oracle7😉

 

 

Posté(e)

Je me répond à moi même et oui ce n'est pas la bonne méthode.

Je pense qu'il faut plutôt ajouter un paramètre "-d" lors du "issue":

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

Il devrait alors créer un certificat valable pour tout les ndd précisés en paramètre.

Par contre je galère pour les déployer ensuite.

Posté(e)

@Double Jo

Bonjour,

il y a 9 minutes, Double Jo a dit :

Par contre je galère pour les déployer ensuite.

Tu n'as que trois fichiers importer sur les clients qui ont besoin de ton certificat. Quel est le soucis alors ?

Cordialement

oracle7😉

Posté(e)

Je pense que c'est bon finalement.

En fait j'ai précisé 3 domaines lors du "issue".
Les 2 premiers étant mon domaine1 et sa wildcard.
Le 3ème paramètre est donc mon domaine2.

Lors du deploy, il m'a fallu absolument mettre la variable 

export SYNO_Create=1

Car en fait il va créer un second certificat (dans la fenêtre des certificats du panneau de config Syno) avec comme description mon domaine2.

Là du coup c'est passé.
Dans le panneau de config donc, je me retrouve avec 2 certifs visibles, qui ont le même nom.
Le premier a une description vide (certif par défaut)
Le second a comme description mon second ndd.

Je lui ai ensuite associé le service web qui doit utiliser ce certificat.

J'avoue que je suis étonné, je m'attendais à ne voir qu'un certif dans le panneau de config.

J'ai un doute quand même...
Je me demande si ce comportement n'est pas un effet secondaire de tous mes tests.

Parce que la description de ce "second" certifcat n'est pas "mondomaine2.com", mais juste "Mondomaine2"

C'est à dire sans le ".com" et avec une majuscule.
Et c'est exactement la description que j'avais mis lorsque j'ai essayé de déployer mon autre certificat quand je voulais en créer plusieurs.

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.