Aller au contenu

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


Einsteinium

Messages recommandés

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 !!!

Lien vers le commentaire
Partager sur d’autres sites

@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 🙂 

Lien vers le commentaire
Partager sur d’autres sites

  • Einsteinium a modifié le titre en [TUTO] Certificat Let's Encrypt avec acme.sh & api Ovh en Docker (DSM6/7) (Update 18/06/21)

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é par tops
Lien vers le commentaire
Partager sur d’autres sites

@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.

Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...

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é par vincentbls
Lien vers le commentaire
Partager sur d’autres sites

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 🙂

Lien vers le commentaire
Partager sur d’autres sites

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é par vincentbls
Lien vers le commentaire
Partager sur d’autres sites

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 .

Lien vers le commentaire
Partager sur d’autres sites

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é par vincentbls
Lien vers le commentaire
Partager sur d’autres sites

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).

Lien vers le commentaire
Partager sur d’autres sites

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é par vincentbls
Lien vers le commentaire
Partager sur d’autres sites

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 😉

Lien vers le commentaire
Partager sur d’autres sites

  • 3 semaines après...

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 candd.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 :confused:...?

Modifié par Ivanovitch
Lien vers le commentaire
Partager sur d’autres sites

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 ...

Lien vers le commentaire
Partager sur d’autres sites

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 ?

Lien vers le commentaire
Partager sur d’autres sites

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.