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

[Kramlech]

il y a 12 minutes, MilesTEG1 a dit :

edit : haaa, en fait j'ai bien cette ligne sur le NAS (pas sur mon ordi)... Elle a du être ajouté par un des scripts car je ne me souvient pas de l'avoir ajouté...

Exact ... Je n'avais pas fait gaffe, mais effectivement cette ligne n'est pas dans le tuto !!!

[MilesTEG1]

@Einsteinium Pour le tuto, ce serait pas mal, je pense, d'ajouter une mention en couleur sur ta dernière édition pour le DEFAULT_ACME_SERVER car certains ont peut-être commencé le tuto sans le finir, et s'ils le reprennent ils ne verront peut-être pas l'ajout.
Et ils ne liront peut-être pas nos derniers échanges, surtout que c'est passé sur une nouvelle page depuis qu'on a évoqué ça 🙂 

[Einsteinium]

Et bien c'est mis en modification en bas de message, maintenant non je ne met pas de couleur, cela poserais quelques problèmes lors des C/C 🙂

A la limite je vais rajouté un update dans le titre du topic.

[tops]

Hello,

Merci pour ce tuto détaillé et très clair.

Mes seuls problèmes ont été :

DOSSIEREXPORT

Je ne sais pourquoi mais au début je pensais qu'il faillait indiquer le répertoire du certificat que l'on souhaite remplacer ... mais s'était tellement illogique car non expliqué. La réponse est donnée dans le fil de discussion : c'est une étape temporaire le temps d'installer pour la première fois le certificat sur le syno.

Donc il faut juste indiquer un répertoire simple d'accès depuis l'interface de création de certificat du syno.

SAVED_SYNO_Scheme='http'
SAVED_SYNO_Hostname='172.17.0.1'
SAVED_SYNO_Port='5000'
SAVED_SYNO_Username='nom utilisateur'
SAVED_SYNO_Password='le password'
SAVED_SYNO_DID=''
SAVED_SYNO_Certificate='description du certificat mise dans le DSM'

J'ai préféré passer en https et rajouter le DID du user dédié ... la bête n'a pas aimé. La solution est donné ici : https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-cert-into-synology-dsm

When using https to connect to "localhost" we need to add the --insecure option to the deploy command. refer to [https://github.com/acmesh-official/acme.sh/wiki/Options-and-Params]. If you enabled HTTP/2 you still receive a curl 16 error but the script succeeds.

Donc la dernière commande devient :

docker exec Acme sh -c "acme.sh --insecure --deploy -d 'mydomain.com' --deploy-hook synology_dsm"

 

 

Le 18/06/2021 à 16:28, MilesTEG1 a dit :

@Einsteinium Pour le tuto, ce serait pas mal, je pense, d'ajouter une mention en couleur sur ta dernière édition pour le DEFAULT_ACME_SERVER car certains ont peut-être commencé le tuto sans le finir, et s'ils le reprennent ils ne verront peut-être pas l'ajout.
Et ils ne liront peut-être pas nos derniers échanges, surtout que c'est passé sur une nouvelle page depuis qu'on a évoqué ça 🙂 

Je te confirme que ton post m'a fait gagner du temps 😀

Modifié le 19 juin 2021 par tops

[Einsteinium]

@tops Merci pour ton retour, par contre inutile de passé en https, c'est du localhost, donc de l’hôte, vers l’hôte  🙂

Concernant le DID, si tu as bien restreint les droits du compte, c'est rajouté une couche supplémentaire qui peut posé problème (avec le DID qui expire) et qui je trouve est inutile, car ce compte admin ne pourra faire que des appels via api, sachant que si tu as bien mis un mot de passe costaud, la seule fuite viendra du account.conf et le DID ne changera rien, vue qu'il si trouve.

Personnellement je rajoute dans le centre de journaux en mot clé de notifications : logged in, signed in & failed, afin d'avoir des notifications de connexion.

[vincentbls]

Bonjour,

Excellent tuto, un grand merci !

Certificat déployé avec succès en changeant pour cette méthode.

Je rebondis sur la question du déploiement automatique : inutile de passer en https car cela se fait en local mais si l'option "Rediriger automatiquement les connexions HTTP vers HTTPS" est activée ne doit-on pas configurer account.conf de la sorte :

SAVED_SYNO_Scheme='https'
SAVED_SYNO_Hostname='172.17.0.1'
SAVED_SYNO_Port='port dsm https ou 443'
SAVED_SYNO_Username='nom utilisateur'
SAVED_SYNO_Password='le password'
SAVED_SYNO_DID=''
SAVED_SYNO_Certificate='description du certificat mise dans le DSM'

Merci.

Modifié le 1 juillet 2021 par vincentbls

[Einsteinium]

C'est du localhost, donc de la machine à elle même, donc sécurisé cette échange est inutile, si l'information passe sur le réseau la oui, mais la ce n'est pas le cas, alors certain diront oui mais si la machine est compromise.. bla bla.. Je répondrais alors que le https ne changera strictera rien à cela 🙂

[vincentbls]

Impossible de me connecter en HTTP ou HTTPS...

Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 3

Unable to authenticate to 172.17.0.1:?XXXX using https (Pourquoi ce ?)

[Einsteinium]

C’est le formatage du log qui veut cela, maintenant ne pas confondre la re direction nginx http/https et cette appel en localhost 😉

Ton dock est bien visible dans le bridge ?

[vincentbls]

il y a une heure, Einsteinium a dit :

Ton dock est bien visible dans le bridge ?

Oui...

Je n'utilise pas les ports 5000 et 5001 par défaut.

Je joins mon NAS via mon nom de domaine et un reverse proxy.

Résolu : je n'avais pas modifié le fichier mydomain.com.conf 

J'ai remplacé l'adresse 172.17.0.1 par l'IP local de mon NAS et de suite ça allait beaucoup mieux 😄

Et il y avait bien une ' qui s'était insérée avant le numéro de port d'où le "?"

Modifié le 1 juillet 2021 par vincentbls

[MilesTEG1]

il y a 33 minutes, vincentbls a dit :

Oui...

Je n'utilise pas les ports 5000 et 5001 par défaut.

Je joins mon NAS via mon nom de domaine et un reverse proxy.

Je fais comme toi, pourtant les scripts de ce tuto fonctionnent avec http dans le fichier de configuration.

il y a une heure, Einsteinium a dit :

Ton dock est bien visible dans le bridge ?

Je pense qu’il veut parler ici du conteneur docker visible dans le réseau bridge docker .

[vincentbls]

Oui, j’avais bien compris.

Sauf erreur de ma part il n’est pas précisé dans le tuto qu’il faille éditer le fichier mydomain.com.conf 

[MilesTEG1]

il y a 35 minutes, vincentbls a dit :

Oui, j’avais bien compris.

Sauf erreur de ma part il n’est pas précisé dans le tuto qu’il faille éditer le fichier mydomain.com.conf 

Je n’ai pas le souvenir de l’avoir modifié ce fichier…

[vincentbls]

Par défaut j’avais la passerelle de mon Docker : connection impossible, plus une ´ avant mon port (??).
J’ai mis l’IP local de mon NAS, enlevé la ‘ : connection immédiate.

[.Shad.]

Normalement on n'a pas à toucher à ce fichier.
Tu as peut-être résolu ce problème temporairement au prix de dysfonctionnements futurs probables.

Si tu pouvais mettre une impression d'écran du fichier de configuration incriminé.

[vincentbls]

Il y a 3 heures, .Shad. a dit :

Normalement on n'a pas à toucher à ce fichier.
Tu as peut-être résolu ce problème temporairement au prix de dysfonctionnements futurs probables.

Si tu pouvais mettre une impression d'écran du fichier de configuration incriminé.

Bonjour,

Pourtant sans intervention impossible de faire le déploiement.

Le contenu du fichier mydomaine.com.conf (Avant/Après) :

Le_Domain='mydomaine.com'
Le_Alt='*.mydomaine.com'
Le_Webroot='dns_ovh'
Le_PreHook=''
Le_PostHook=''
Le_RenewHook=''
Le_API='https://acme-v02.api.letsencrypt.org/directory'
Le_Keylength='4096'
Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/XXX'
Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/XXX'
Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/XXX'
Le_CertCreateTime='1625132007'
Le_CertCreateTimeStr='Thu Jul  1 09:33:27 UTC 2021'
Le_NextRenewTimeStr='Mon Aug 30 09:33:27 UTC 2021'
Le_NextRenewTime='1630229607'
Le_DeployHook='synology_dsm,'
SAVED_SYNO_Scheme='https'
SAVED_SYNO_Hostname='172.17.0.1'/'192.168.2.10'
SAVED_SYNO_Port=''XXXXX'/'XXXXX'
SAVED_SYNO_Username='XXX'
SAVED_SYNO_Password='XXXXXXXXXXXX'
SAVED_SYNO_DID=''
SAVED_SYNO_Certificate='__ACME_BASE64__START_XXXXXXXXXXXXXXX=__ACME_BASE64__END_'

Même cas ici 

Modifié le 2 juillet 2021 par vincentbls

[.Shad.]

C'est étrange car ça devrait fonctionner.
Est-ce que tu peux taper ceci en SSH et en poster le résultat :

docker network inspect bridge

Pense à ajouter sudo devant si tu n'es pas connecté via l'utilisateur root.

Et vérifier dans le pare-feu de ton NAS que tu autorises les IP 172.16.0.0/12 (mais je doute que ce soit ça car si c'était interdit, même avec l'IP locale ça ne passerait pas).

A la place de l'IP locale tu peux aussi utiliser le nom NetBIOS normalement, moins de chance que le nom change contrairement à l'IP (changement de box, réorganisation du réseau, etc... pas sûr que tu penses à màj le script... c'est l'avantage de l'IP passerelle qui ne change jamais).

[vincentbls]

Les IP sont bien autorisés dans le pare-feu. L'IP local du NAS est fixée.

Résultat commande (je n'ai laissé que le container acme) :

[

    {

        "Name": "bridge",

        "Id": "7aa46b86d97227a723be9f679de08843a3aae486dd2f19770c0967e13610a600",

        "Created": "2021-06-29T17:19:14.136988784+02:00",

        "Scope": "local",

        "Driver": "bridge",

        "EnableIPv6": false,

        "IPAM": {

            "Driver": "default",

            "Options": null,

            "Config": [

                {

                    "Subnet": "172.17.0.0/16",

                    "Gateway": "172.17.0.1"

                }

            ]

        },

        "Internal": false,

        "Attachable": false,

        "Ingress": false,

        "ConfigFrom": {

            "Network": ""

        },

        "ConfigOnly": false,

        "Containers": {

            "9bfe087a7b90864abecd993bdda871e9d3ae0a0a48094526112c7b9663710c12": {

                "Name": "acme",

                "EndpointID": "1c1076683db7ccdd877f6b56769799ff47eacdb7af009151722d46e7f280437c",

                "MacAddress": "",

                "IPv4Address": "172.17.0.13/16",

                "IPv6Address": ""

        },

        "Options": {

            "com.docker.network.bridge.default_bridge": "true",

            "com.docker.network.bridge.enable_icc": "true",

            "com.docker.network.bridge.enable_ip_masquerade": "true",

            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",

            "com.docker.network.bridge.name": "docker0",

            "com.docker.network.driver.mtu": "1500"

        },

        "Labels": {}

    }

]

Modifié le 2 juillet 2021 par vincentbls

[Einsteinium]

Il y a 4 heures, vincentbls a dit :

mydomaine.com.conf

Ce fichier reprends les données de myaccount.conf, les nouvelles variables s’y transmettent, si tu avait déjà une erreur à l’origine avec un ? En trop… forcément cela n’aide pas.

concernant l’ip… le https ne fonctionne pas en localhost (172.17.0.1), mais bien en attaquant l’ip directement du nas. (Port 443 pas ouvert en localhost)

Comme dit dans le tutoriel… https inutile en localhost 😉

[vincentbls]

C’est une apostrophe qui s’était insérée et qui retournait un « ? » dans le terminal, sûrement moi le fautif avec les Ctlr-C et le formatage.
J’entends bien pour le https mais si les redirections
http->https sont forcées dans les paramètres du NAS ?

[Ivanovitch]

salut à tous et un grand merci pour le tuto !

est-ce que vous rencontrez des problèmes aléatoires avec les APIs OVH ?

Elle sont super instables chez moi: un coup tout passe, un coup c'est un des deux txt record add qui fail (du coup pas de cert derrière), un coup c'est le delete record qui fail (donc cert obtenu mais ca poubellise ma zone DNS)...

je précise que quand c'est 100% OK ou quand j'ai juste erreur sur la suppression d'un des record txt je peux continuer et déployer le cert sans soucis.

j'ai supprimé puis recrée les API plusieurs fois: ça ne change rien. Surtout, si elles étaient crées NOK ca ne passerai jamais...

https://api.ovh.com/createToken/?GET=/domain/zone/ndd.tld/*&POST=/domain/zone/ndd.tld/*&PUT=/domain/zone/ndd.tld/*&GET=/domain/zone/ndd.tld&DELETE=/domain/zone/ndd.tld/record/*

pas d'espace alakon ni rien

donc voici ma procédure de test

ssh root (pas sudo, vrai root par clé)

docker run --rm -itd --name=AcmeSSL -v /volume1/docker/AcmeSSL:/acme.sh neilpang/acme.sh daemon

puis la boucle de test en elle même:

1. docker exec AcmeSSL --issue --keylength 4096 -d ndd.tld -d *.ndd.tld --dns dns_ovh --test
2. suppr dossiers ca & ndd.tld du volume (pour pouvoir boucler sans se manger un 'domain already verified')
3. go to 1

utilisation du --test pour utiliser les serveurs staging de LE, histoire de pas consommer les 5 certs/semaine

comme je lance le docker en --rm je peux éventuellement faire un RAZ total en faisant un docker stop AcmeSSL
mais en pratique ca change rien à l'occurrence

je vais essayer de faire flow de test un peu plus debuggable avec un soft genre Postman, mais déjà si des gens ici ont une idée / observent la même chose ...?

Modifié le 19 juillet 2021 par Ivanovitch

[Einsteinium]

Apparemment j’ai certains quelques bug oui, mais en général cela passe le lendemain, après cela peu venir aussi bien de ovh que de le, faut faire avec, les rares  maintenance doivent ce faire la nuit je penses.

[bruno78]

Bonjour @Ivanovitch,

j'ai eu également ces derniers jours beaucoup (trop ?) d'erreurs de renouvellement de certificats à cause des enregistrements TXT.

Du coup, via l'API OVH, j'ai un script qui tourne et "nettoie" systématiquement les enregistrements TXT de type "_acme-challenge" (dans la terminologie OVH : fieldType='TXT',subDomain='_acme-challenge'). Je n'ai pas suffisemment de recul, mais pour le moment, mais je n'ai plus d’échec de renouvellement sur les 2 dernières tentatives.

C'est un petit script python qui tourne quotidiennement sur un RPI4. Si intéressé(s), me faire signe ...

[Einsteinium]

Bah tu peux le poster Bruno, cela servira à certains 😉

[MilesTEG1]

il y a 10 minutes, bruno78 a dit :

Bonjour @Ivanovitch,

j'ai eu également ces derniers jours beaucoup (trop ?) d'erreurs de renouvellement de certificats à cause des enregistrements TXT.

Du coup, via l'API OVH, j'ai un script qui tourne et "nettoie" systématiquement les enregistrements TXT de type "_acme-challenge" (dans la terminologie OVH : fieldType='TXT',subDomain='_acme-challenge'). Je n'ai pas suffisemment de recul, mais pour le moment, mais je n'ai plus d’échec de renouvellement sur les 2 dernières tentatives.

C'est un petit script python qui tourne quotidiennement sur un RPI4. Si intéressé(s), me faire signe ...

Je viens de vérifier, je n'ai qu'une entrée TXT dans la zone DNS de mon nom de domaine OVH.

Qu'est-ce qui fait qu'il pourrait y en avoir plusieurs ?

Perso, je n'ai programmé le lancement du script acme_2C-quotidien.sh tous les dimanches plutôt que tous les jours.

Et dimanche dernier, j'ai pu voir que la date de validité du certificat wildcards a été poussé au 14/10/21 😄 
Donc pour le moment tout fonctionne bien 😉 

Vous voulez voir les logs ?