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

[PPJP]

Bonjour @bruno78,

Je n’ai pas parcouru les 4 pages de ce tutoriel, j’ai seulement lu votre dernier message.

 

A partir de la situation que vous décrivez, il vous manque pour finir ce script.

 

Dans un premier temps vous devez,  en exploitant le dossier INFO (pour ce qui concerne ce nouveau certificat) :

- Copier les nouveaux dossiers du certificat dans les dossiers des packages concernés puis redémarrer ceux-ci

- Copier les nouveaux dossiers du certificat dans les dossiers des reverse-proxies concernés

- redémarrer ngix,

 

Cependant vous constaterez qu’ainsi vous avez redémarré des packages qui étaient arrêtés avant le renouvellement du certificat

Dans un second temps vous devez donc tester et mémoriser l’état initial des packages afin de ne relancer que ceux qui étaient précédemment actifs.

 

Et pour finir une (petite) remarque :

Cela étant un tuto, je trouve dommage de proposer un script en Python, car cela nécessitera d’installer ce paquet. Si c’est pour cette seule utilisation, je trouve cela dommage.

[bruno78]

@PPJP

waouh !! . Bon d'abord merci PPJP. Effectivement ces aspects étaient passés sous le radar. Là du coup je crains que ce ne soit un peu (beaucoup) au delà de mes capacités, soyons honnête.

Quand au Python, il faut avouer que pour traiter un fichier .json, c'est pratique. Quel outil natif proposerais-tu dans ce cas ?

Merci en tout cas de t'être intéressé au sujet.

Bruno78

 

 

[PPJP]

@bruno78

Pour mes besoins, sur les NAS où j’interviens, je ne code presque qu’exclusivement en Python.

Je n’ai pratiqué le shell que pour aider sur quelques scripts de tuto de ce forum où je suis intervenu.

Je le connais donc que très mal et trouve sa lecture pénible (manque de pratique)

 

Les fichiers json se traitent en shell avec jq.

 

J’essaierai de passer sur ce forum de temps en temps pour voir où vous en êtes.

Si vous êtes bloqués j’essaierai de vous aider.

 

Bon courage

[bruno78]

@PPJP

merci.

La tache semble lourde ! Je ne lâche pas le sujet, mais ça risque de prendre du temps. Je vais regarder jq que je ne connais pas. Et peut-être en parallèle continuer malgré tout en Python pour valider l'ensemble de la mécanique ..... .

[PPJP]

@bruno78

Le manuel de jq : https://stedolan.github.io/jq/manual/

[oracle7]

@PPJP

Bonjour,

il y a 54 minutes, PPJP a dit :

J’essaierai de passer sur ce forum de temps en temps pour voir où vous en êtes.

Si vous êtes bloqués j’essaierai de vous aider.

Effectivement ce serait vraiment sympa de ta part car il ne nous manque pas grand chose manifestement pour avoir une procédure complète, de bout en bout, pour générer, renouveler et gérer sur nos NAS ce fameux certificat wilcard LE.

Cordialement

oracle7😉

 

[TuringFan]

Le 20/06/2020 à 11:48, oracle7 a dit :

@TuringFan

Bonjour,

C'est une belle colle que tu me poses là.

J'avoue ne pas trop savoir. Pour ma part j'avais procédé comme je te l'ai indiqué précédemment en important les 3 fichiers issus de la génération. Force est de constaté que je n'ai pas rencontré les problèmes que tu évoques. Du coup je suis un peu sec pour te répondre.

A tout hasard, as-tu essayé d'arrêter proprement le RT, de le débrancher électriquement, attendre au moins une minute et de le redémarrer tout aussi proprement, histoire que tous les caches mémoire soient bien vidés. Ensuite, tu réimportes les trois fichiers du certificat . Cela ce coûte rien d'essayer et peut être que ...

Cordialement

oracle7😉

Bonjour @oracle7,

Je viens d'essayer et toujours le même message d’erreur sur l'illégalité du certificat intermédiaire.

je vais essayer d'investiguer car très contraignant : cela rend le VPN SSL inopérant.

Cordialement,

[oracle7]

@TuringFan

Bonjour,

Ok, alors je crois alors qu'il y a un bémol avec ton fichier "ca.cer", il a dû être endommagé pour x raisons.

Pour le vérifier:

• avec WINSCP recherche dans "/usr/syno/etc/certificate/_archive" le dossier "XyzWTu" de ton dernier certificat (en principe le plus récent mais en tout cas celui qui est cohérent avec la date de génération du certificat)
• ouvre ce dossier et récupère sur ton PC une copie du fichier "chain.pem" qui s'y trouve.
• compare en visualisant en cote à cote ce fichier avec une copie du "ca.cer" pris dans "volume1/Certs/ndd.tld" pour t'assurer qu'ils sont en principe identiques dans leur contenu (mis à part d'éventuels caractères parasites invisibles qui pourraient s'y trouver)
• ensuite sur le PC tu renommes le fichier "chain.pem" en  "ca.cer"
• puis refait un import dans le RT du certificat "ndd.tld.key", "ndd.tld.cer" et en fichier intermédiaire le "nouveau "ca.cer"

Si cela passe alors BINGO ! Sinon là je sèche et je vais tout de même pas te dire de relancer une génération complète...

Cordialement

oracle7😉

 

[TuringFan]

Merci pour ton retour @oracle7,

J'ai bien ca.cer et chain.pem qui sont identiques au caractère près mais toujours ce problème d'illégalité du certifcat intermédiaire !

Je vais relancer une installation complète : y a t il une manipulation préliminaire spécifique à faire ? Comme par exemple supprimer certains dossiers/fichiers avant de relancer la génération ?

PS : j'ai remarqué sur mon NAS que mon certificat Wilcard était pour "-" (soit rien en fait) bien qu'il soit le certificat par défaut. Est-ce normal ?

Merci d'avance,

[oracle7]

@TuringFan

Bonjour,

Il y a 10 heures, TuringFan a dit :

PS : j'ai remarqué sur mon NAS que mon certificat Wilcard était pour "-" (soit rien en fait) bien qu'il soit le certificat par défaut. Est-ce normal ?

Ce n'est pas normal dans le sens où tu n'as pas réaffecté/configuré le certificat aux services qui doivent l'utiliser. Voir "Panneau de configuration / Sécurité / Certificat / Configurer". Donc peut-être pas de réinstallation complète à faire ... Enfin pas pour ce motif précis !

C'est justement le problème que l'on essaie de régler avec @Bruno78 pour automatiser de bout en bout la procédure. Après la génération du nouveau certificat celui-ci devient bien le certificat par défaut mais il faut encore intervenir MANUELLEMENT pour affecter ce certificat aux services qui l'utilisent (piège si je puis dire dans lequel tu est manifestement tombé 😪pourtant on en parle dans les commentaires ci-avant).

Il y a 11 heures, TuringFan a dit :

une installation complète : y a t il une manipulation préliminaire spécifique à faire ?

Si c'est du NAS, de mémoire a priori non (sauf omission de ma part) mais est-ce vraiment utile ? Sauf si tu as fait tout un tas d'essais de configuration dans tous les sens alors peut-être que cela serait utile histoire effectivement de repartir sur une base saine maintenant que tu maîtrises aussi certains concepts. C'est juste du temps et pas mal de manipulations ... mais pas insurmontable avec un tant soit peu d'attention et de méthode.

Cordialement

oracle7😉

[oudin]

Un grand merci @oracle7pour ce tuto, suivi à la lettre et tout est OK sur mes deux NAS, un DS218+ et un DS214+.

La suite dans 3 mois😀

[vincentbls]

Bonjour,

J'ai fait ça hier après plusieurs recherches et j'ai préféré utiliser acme.sh avec Docker. 

De plus, j'ai configuré une tâche qui vient copier automatiquement les certificats dans le répertoire approprié.

Voici la procédure que j'ai montée avec OVH et qui fonctionne chez moi (en anglais) :

• Log into Synology DSM and open Docker app
• In the Registry, search and find neilpang/acme.sh. Download the latest image.
• Launch the container with the downloaded neilpang/acme.sh image
• Go to Advanced setting, map the volume folder docker/acme with /acme.sh and set the container network to use the same as host. Environment command ‘daemon’
• Then start the container with auto-restart
• Go to container Terminal – Create – Launch with command
• Enter a command: ‘sh’

1. Create application key and secret

https://eu.api.ovh.com/createApp/

2. Set api key and api secret.

# application key

export OVH_AK="votre_api_key"

# application secret

export OVH_AS="votre_api_secret"

acme.sh --issue -d nomdomaine.nd -d *.nomdomaine.nd --dns dns_ovh

If you are first time using OVH api, you are required to authenticate the api. (This only happens the first time.)

You will see some thing like bellow :

[Thu, Aug 25, 2016 10:54:03] Using OVH endpoint: ovh-eu

[Thu, Aug 25, 2016 10:54:04] OVH consumer key is empty, Let's get one:

[Thu, Aug 25, 2016 10:54:05] Please open this link to do authentication: https://eu.api.ovh.com/auth/?credentialToken=n0Qbjm6wBdBr2KiSqIuYSEnixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[Thu, Aug 25, 2016 10:54:05] Here is a guide for you: https://github.com/Neilpang/acme.sh/wiki/How-to-use-OVH-domain-api

[Thu, Aug 25, 2016 10:54:05] Please retry after the authentication is done.

[Thu, Aug 25, 2016 10:54:05] Error add txt for domain:_acme-challenge.mytest.mydomain.com

3. Authentication the api key. (This only happens the first time.)

Open the link above :

https://eu.api.ovh.com/auth/?credentialToken=n0Qbjm6wBdBr2KiSqIuYSEnixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

In the page, please select "Unlimited" for the Validity. 

Click "Authorize Access"

4. Then go back to try again.

acme.sh --issue -d nomdomaine.nd -d *.nomdomaine.nd --dns dns_ovh

• After successfully issue the certificate, the cert files will be stored at /volume1/docker/acme/nomdomaine.nd
• You can now create a scheduled task (every month) in DSM to regularly copy cert files to DSM system directories :

docker exec neilpang-acme.sh acme.sh --issue --force --dns dns_ovh -d nomdomaine.nd -d *.nomdomaine.nd 

sleep 2m

rsync -avh "/volume1/docker/acme/nomdomaine.nd/nomdomaine.nd.cer" "/usr/syno/etc/certificate/_archive/Random PATH/cert.pem"

rsync -avh "/volume1/docker/acme/nomdomaine.nd/nomdomaine.nd.key" "/usr/syno/etc/certificate/_archive/Random PATH/privkey.pem"

rsync -avh "/volume1/docker/acme/nomdomaine.nd/fullchain.cer" "/usr/syno/etc/certificate/_archive/Random PATH/fullchain.pem"

rsync -avh "/volume1/docker/acme/nomdomaine.nd/ca.cer" "/usr/syno/etc/certificate/_archive/Random PATH/chain.pem"

/usr/syno/etc/rc.sysv/nginx.sh reload

Pour connaître le chemin "Random PATH," connexion SSH au NAS puis sudo -i : ls /usr/syno/etc/certificate/_archive

Modifié le 25 juin 2020 par vincentbls

[oracle7]

@vincentbls

Bonjour,

Effectivement, passer par un conteneur docker est une autre façon d'utiliser ACME. Pourquoi pas mais n'oublies pas que jouer avec "docker" n'est pas abordable à tout le monde ...

Cela dit, et je ne voudrais pas passer pour un rabat joie, mais au final tu en es au même point que nous. Avec ta procédure qui reste la procédure "standard" d'utilisation d'ACME (même en passant par docker), tu es quand même obligé d'avoir une action manuelle. Pour le cas : trouver le bon répertoire "Ramdom PATH" afin d'assurer le déploiement du certificat.

Ce que l'on recherche avec @bruno78 c'est une automatisation TOTALE  du processus création, renouvellement et de déploiement du certificat LE.

PS :

Citation

docker exec neilpang-acme.sh acme.sh --issue --force --dns dns_ovh -d nomdomaine.nd -d *.nomdomaine.nd --dns dns_ovh

Attention tu as 2 fois l'instruction "--dns dns_ovh" dans ta commande !

Cordialement

oracle7😉

[vincentbls]

1. Personnellement je trouve cela plus simple, d'autant plus que la configuration du container est basique.

2. Et normalement l'intérêt de passer par Docker consiste à laisser le container s'exécuter avec la commande "Daemon" : "Execution Command : /entry.sh daemon"

Ainsi, si tout se passe bien, acme.sh vérifiera si le certificat émis doit être renouvelé. Pas besoin de forcer le renouvellement.

Ensuite, le script paramétré comme tâche est censé se charger de copier régulièrement les fichiers cert dans les répertoires système de DSM.

Pour connaître le chemin : ls /usr/syno/etc/certificate/_archive (voir capture).

Testé hier, plusieurs fois, je retrouve bien mon certificat dans le menu du même nom de DSM.

3. Exact, bien vu ! Mauvais copier-coller 😉 C'est corrigé.

[bruno78]

Bonjour @vincentbls

il y a 8 minutes, vincentbls a dit :

Ensuite, le script paramétré comme tâche est censé se charger de copier régulièrement les fichiers cert dans les répertoires système de DSM.

Pour connaître le chemin : ls /usr/syno/etc/certificate/_archive

certes, mais tu vas te rendre compte, comme nous, que cela ne suffit pas. Voir, entre autre, le post de @PPJP un peu plus haut. Avoir les nouveaux certificats dans ./_archive est insuffisant (nous aussi on y a cru !).

J'ai quasiment terminé mon script pour automatiser ce déploiement, j'espère pouvoir tester ce weekend .... (j'ai d'ailleurs inclus un test de date de renouvellement (T0+60j), afin de pouvoir se passer de l'option --force)

Modifié le 25 juin 2020 par bruno78

[oracle7]

@vincentbls

il y a 3 minutes, vincentbls a dit :

Ensuite, le script paramétré comme tâche est censé se charger de copier régulièrement les fichiers cert dans les répertoires système de DSM.

Sauf que ce n'est pas suffisant ! Tu es quand même obligé de configurer manuellement les différents services qui utilisent ton  nouveau certificat.

il y a 6 minutes, vincentbls a dit :

Testé hier, plusieurs fois, je retrouve bien mon certificat dans le menu du même nom de DSM.

Bien le retrouver est une chose mais je te renvoie à mon argumentaire ci-dessus.

Cordialement

oracle7😉

@bruno78

Nos réponses se sont croisées ...

Par ailleurs, c'est une bonne nouvelle que tu nous annonces là ! 😀 Prends le temps qu'il te faut pour bien tester ...

Cordialement

oracle7😉

[vincentbls]

il y a 6 minutes, oracle7 a dit :

Sauf que ce n'est pas suffisant ! Tu es quand même obligé de configurer manuellement les différents services qui utilisent ton  nouveau certificat.

Alors non, ce n'est pas encore bon... @bruno78 J'y ai cru aussi !

J'avoue que je n'ai pas lu tout le fil... 🙂

Modifié le 25 juin 2020 par vincentbls

[vincentbls]

Je reviens à la charge car je viens de refaire la manip : mon nouveau certificat par défaut est bien installé avec tous les services associés, sans aucune intervention de ma part.

Précision : je n'en ai qu'un.

[bruno78]

@vincentbls,

oui, si on regarde sur l'interface graphique du DSM (securité > certificat), le certificat est installé et on y voit les services associés. Maintenant si tu effaces le cache de ton navigateur, et que tu recharges le site en question, puis que tu examines le certificat utilisé par le navigateur, je suis prêt à parier que c'est toujours l'ancien (verifie par exemple la date d'expiration). En fait il en est ainsi, pour un certificat web, car dans la procedure tu n'as pas mis à jour les fichiers *.pem dans le repertoire /usr/local/etc/certificate/WebStation/vhost_xxxxx correspondant. Ce sont toujours les anciens fichiers.

[oracle7]

@vincentbls

il y a 8 minutes, vincentbls a dit :

Précision : je n'en ai qu'un.

Tu fais bien de préciser. Forcément que dans ce cas tu ne vois aucune différence, mais le jour où tu auras plusieurs certificats comme moi, ce ne sera plus du tout la même musique ... Ton nouveau certificat ne sera pas affecté (même après renouvellement) et tu auras des alertes de sécurité ...

Pourquoi crois-tu que l'on soit plusieurs à plancher sur le problème ?

Cordialement

oracle7😉

[vincentbls]

Il y a 2 heures, bruno78 a dit :

@vincentbls,

oui, si on regarde sur l'interface graphique du DSM (securité > certificat), le certificat est installé et on y voit les services associés. Maintenant si tu effaces le cache de ton navigateur, et que tu recharges le site en question, puis que tu examines le certificat utilisé par le navigateur, je suis prêt à parier que c'est toujours l'ancien (verifie par exemple la date d'expiration). En fait il en est ainsi, pour un certificat web, car dans la procedure tu n'as pas mis à jour les fichiers *.pem dans le repertoire /usr/local/etc/certificate/WebStation/vhost_xxxxx correspondant. Ce sont toujours les anciens fichiers.

Hélas, oui.

Le 21/06/2020 à 22:02, TuringFan a dit :

Je viens d'essayer et toujours le même message d’erreur sur l'illégalité du certificat intermédiaire.

Bonjour @TuringFan,

J'ai eu le même problème : après examen du fichier ca.cer avec un simple éditeur de texte, il y a un saut de ligne au début de -----BEGIN CERTIFICATE----- (Pourquoi ?).

En le supprimant ça passe.

Modifié le 25 juin 2020 par vincentbls

[vincentbls]

il y a 22 minutes, oracle7 a dit :

Pourquoi crois-tu que l'on soit plusieurs à plancher sur le problème ?

J'essaye de comprendre, je n'ai pas les compétences suffisantes pour apporter une solution 🙂

[oracle7]

@vincentbls et @TuringFan

il y a 24 minutes, vincentbls a dit :

J'ai eu le même problème : après examen du fichier ca.cer avec un simple éditeur de texte, il y a un saut de ligne au début de -----BEGIN CERTIFICATE----- (Pourquoi ?).

En le supprimant ça passe.

Pour le coup, c'est une excellente information. Merci du tuyau. Comme quoi certains problèmes ne tiennent à pas grand chose. Il faut juste les voir ...

Cordialement

oracle7😉

[vincentbls]

il y a 38 minutes, bruno78 a dit :

En fait il en est ainsi, pour un certificat web, car dans la procedure tu n'as pas mis à jour les fichiers *.pem dans le repertoire /usr/local/etc/certificate/WebStation/vhost_xxxxx correspondant. Ce sont toujours les anciens fichiers.

Puis-je faire la manipulation manuellement en attendant ?

[bruno78]

@vincentbls

oui ca doit passer manuellement. Sauvegarde tes anciens fichiers *.pem avant. Ensuite, je ne suis pas certain de la nécessité de redemarrer, ou pas, nginx.  Il me semble avoir constaté que cela est pris en compte même sans redemarrer nginx, ... mais bon au cas ou ....