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

[MilesTEG1]

@oracle7 @Einsteinium
Je viens de supprimer le conteneur créé avec le docker run, et recréer via Portainer avec ce docker-compose.yml :
 

###########################################################################
#                         Docker-compose pour ACME                        #
###########################################################################

# ==========================================================
# == Version qui remplace le script des tâches planifiées ==
# ==========================================================
#
# Doc de Acme.sh : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide
#                  https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-cert-into-synology-dsm
#                  https://github.com/acmesh-official/acme.sh
#
# Depot GitHub : https://github.com/acmesh-official/acme.sh/wiki/Run-acme.sh-in-docker
#
---
version: "2.4"
services:
  acme:
    image: neilpang/acme.sh:latest    # https://github.com/acmesh-official/acme.sh/wiki/Run-acme.sh-in-docker

    container_name: Acme
    networks:
      acme_network:
        ipv4_address: 172.29.0.2

    # Exécutez acme.sh en tant que démon docker, afin qu'il puisse gérer automatiquement la tâche cron de renouvellement.
    command: daemon

    cpu_shares: 10
    mem_limit: 128M

    # ###############
    # Le label ci-dessous permet à Watchtower de faire les mises à jour automatiquement
    # Cela peut-être supprimé si Watchtower n'est pas utilisé.
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    # ###############

    volumes:
      - /volume1/docker/Acme:/acme.sh:rw

    restart: unless-stopped

networks:
  acme_network:
    ipam:
      driver: default
      config:
        - subnet: 172.29.0.0/16
          gateway: 172.29.0.1
    name: acme_network

Comment puis-je être sûr de son bon fonctionnement ?
Car le log n'indique plus rien dans portainer :

 

Et le fichier log dans le dossier docker/acme/ n'indique pas d'action datant de mon installation du docker-compose...

[oracle7]

@MilesTEG1

Bonjour,

Si cela peut te rassurer en quelque sorte (quoique !), je n'ai pas non plus d'infos de logs dans portainer. Tout au plus j'ai "stop" à chaque arrêt du conteneur visualisé avec "docker logs -f Acme". Mais rien d'autre.

 

[MilesTEG1]

il y a une heure, oracle7 a dit :

@MilesTEG1

Bonjour,

Si cela peut te rassurer en quelque sorte (quoique !), je n'ai pas non plus d'infos de logs dans portainer. Tout au plus j'ai "stop" à chaque arrêt du conteneur visualisé avec "docker logs -f Acme". Mais rien d'autre.

Ok, ça ne me rassure pas forcément, mais au moins je ne suis pas le seul, et si tu n'es pas inquiété 😄 

 

PS : si tu utilises Portainer, évite les v3 de docker-compose. C'est ce qu'on m'a dit une fois ^^ Qu'il vallait mieux rester sur du 2.x, genre 2.4 ou le max 2.9 😉 

[Einsteinium]

Normalement le log doit être crédité tous les jours d'un essai

[oracle7]

@Einsteinium

Bonjour,

Le 08/09/2022 à 18:51, Einsteinium a dit :

Normalement le log doit être crédité tous les jours d'un essai

C'est ce à quoi je m'attendais mais non ! le log reste désespérent vide ... 🥴

Je crains qu'il y ait un problème dans l'image acme, mais je peux me tromper.

Cordialement

oracle7😉

[Einsteinium]

J’ai l’image du docker à jour, acme cherche un update en prime sur le github chaque nuit avant le test de renew.

J’ai stoppé le docker et mis en bak le log actuel, au lancement il ne m’a pas refait le log vierge, on verra s’il est créé d’ici demain avec le test de renew.

Je viendrais faire un retour.

[Einsteinium]

Le log à bien été recréer lors du test de cette nuit.

Tu a bien dans le config les bonnes "" et l'encodage en Text ?

LOG_FILE="/acme.sh/acme.sh.log"
LOG_LEVEL=1

Essaye sa suppression et relance le docker voir s'il le créera au prochain test, J'ai récréer un nouveau docker et je n'arrive pas à reproduire ce bug.

Niveau permission, root propriétaire et en avancées type autoriser

root : controle total

administrators : lire & écrire

everyone : lire

[MilesTEG1]

De mon côté, le conteneur s'est bien lancé, et le log a eu ces lignes d'écrites (plus d'autres après) :

[Einsteinium]

Il y a 1 heure, MilesTEG1 a dit :

ces lignes d'écrites

Ouaip c'est la Maj de acme ( a ne pas confondre avec l'image du docker)

[oracle7]

@Einsteinium

Bonjour,

Bon bah moi y a na pas comprendre ???

Tout est OK pour la syntaxe, pour les droits sur fichiers et dossiers, etc ... J'ai même essayé avec un LOG_LEVEL=2 après avoir tué le conteneur puis recréé mais toujours pareil : aucuns logs ! 🥴

AUtant les premières fois j'avais au moins un 'stop' lors de la supression du conteneur, que maintenant plus rien , zéro, nada ...

Je dois trainer autre chose mais quoi ? Mystère ?

D'autres pistes à explorer ?

Cordialement

oracle7😉

Edit : Après un arrêt complet du package docker puis relancé, j'ai retrouvé au moins un 'stop' dans le log d'acme. A voir la suite ...

Modifié le 11 septembre 2022 par oracle7

[MilesTEG1]

Il y a 6 heures, Einsteinium a dit :

Ouaip c'est la Maj de acme ( a ne pas confondre avec l'image du docker)

Du coup c’est bon chez moi , ça fonctionne comme il faut ?

qu’entends tu par « l’image du docker » ?

[Einsteinium]

Il y a 3 heures, MilesTEG1 a dit :

qu’entends tu par « l’image du docker » ?

L’image que tu pull, qui contient un ensemble de dépendance pour faire tourné le programme (acme dans le cas présent)

Il y a 3 heures, MilesTEG1 a dit :

Du coup c’est bon chez moi , ça fonctionne comme il faut ?

Oui rock & roll

[TuringFan]

Bonjour @Einsteinium et merci pour ce tuto.

Merci car je viens de le suivre avec succès et à mes yeux il s'agit d'un tuto facile/rapide à déployer !

J'ai néanmoins des questions (en gras ci-dessous) assez naïves pour bien comprendre ce que j'ai fait. je suis certain que cela pourra en aider d'autres.

Je viens de migrer sur DSM 7 et j'utilisais historiquement le tuto de @oracle7 qui marchait plutôt bien de mon côté. je cherchais justement une méthode moins dépendante de l'environnement (et des migrations) et si je comprends bien c'est le gros point fort de cette méthode est qu'elle utilise les dockers (technologie que je ne maitrise absolument pas) . 

A noter pour ceux dont le NAS n'est pas officiellement/nativement compatible avec Docker, vous pouvez télécharger le paquet sur le centre de téléchargement Synology (en indiquant un NAS compatible) et ensuite l'installer manuellement depuis le centre de paquet. Cela semble fonctionner chez moi.

L'utilisation de docker apporte-t-elle autre chose que je n'ai pas indiqué/compris ?

Le 11/10/2020 à 12:58, Einsteinium a dit :

C Bis) Le docker-compose.yml :

version: "2.1"
services:
  acme:
    cpu_shares: 10
    mem_limit: 128M
    container_name: Acme
    network_mode: bridge
    labels:
      - com.centurylinklabs.watchtower.enable=true
    volumes:
      - /volume1/docker/Acme:/acme.sh:rw
    restart: unless-stopped
    image: neilpang/acme.sh:latest
    command: daemon

Je n'ai pas compris l'utilité et la fonction de cette partie (que j'ai donc ignorée) ? Est-ce un équivalent, via un outil type Portainer, à la création du conteneur acme.sh via le planificateur de tache DSM ?

Par ailleurs si j'ai bien compris la configuration obtenu en suivant ce tutoriel permet une renouvellement puis déploiement automatique du certificat sur le NAS. Sauf erreur de ma part le renouvellement est alors assuré par l'appel du script acme.sh via la tache récurrente (programmée quotidiennement à 5h dans le tuto).

Question naïve mais où est hébergé le script acme.sh ?
Comment celui-ci fonctionne-t-il : j'imagine qu'il fait un check de la date d'échéance du Certificat et le renouvelle quand on s'en approche ? Si oui de combien de temps avant l'échéance le renouvellement est il autorisé ? Est-ce paramétrable ?

Après avoir renouvelé puis déployé manuellement le certificat j'ai exécuté la tache de déploiement automatique mais il ne s'est absolument rien passé ... Est-ce normal ?

Serait-il par ailleurs possible d'automatiser le déploiement à mon routeur Synology qui est en amont de mon NAS sur mon réseau ?

D'un point de vue sécurité je crois comprendre qu'on ne peut pas chiffrer le dossier partagé Docker. Hors celui-ci contient des éléments confidentiels comme (i) les fichiers du certificat ou (ii) les clés API de notre registraire (OVH dans ce tuto).

J'ai aussi noté que le fichier de config faisait référence à du HTTP (avec un port 5000) plutôt que du HTTPS (avec un port 5001). 

Je ne maitrise pas ces sujets mais est-il possible d'améliorer la sécurité de cette configuration (chiffrement dossier partagé + protocole HTTPS) ?

Une autre question naïve mais comment désactiver un jeu de clés API chez OVH ?

Enfin une question plus générale : je viens de commander un routeur et un second NAS (plus petit) que je compte mettre sur un site distant de mon premier NAS pour effectuer des backups. Pourrais-je me utiliser le même certificat ? Si la réponse est non, comment faire ? Je me permets de taguer @bruno78 car au regard de tes commentaires tu pourrais avoir la réponse ...

Merci d'avance pour votre aide,

[Einsteinium]

il y a 37 minutes, TuringFan a dit :

Je n'ai pas compris l'utilité et la fonction de cette partie (que j'ai donc ignorée) ? Est-ce un équivalent, via un outil type Portainer, à la création du conteneur acme.sh via le planificateur de tache DSM ?

C’est une alternative pour ceux qui utilisent portainer effectivement, ce que tu peux ignoré dans ton cas 🙂

il y a 37 minutes, TuringFan a dit :

Question naïve mais où est hébergé le script acme.sh ?
Comment celui-ci fonctionne-t-il : j'imagine qu'il fait un check de la date d'échéance du Certificat et le renouvelle quand on s'en approche ? Si oui de combien de temps avant l'échéance le renouvellement est il autorisé ? Est-ce paramétrable ?

Il actualise le certificat un mois avant l’échéance, soit tous les deux mois.

Tu peux néanmoins programmé une tâche pour son renouvellement plutôt, mais c’est vraiment inutile.

il y a 40 minutes, TuringFan a dit :

Est-ce normal ?

Oui, cela permet juste d’initialiser la tâche de déploiement automatique dans dsm pour les prochaines fois.

il y a 41 minutes, TuringFan a dit :

Serait-il par ailleurs possible d'automatiser le déploiement à mon routeur Synology qui est en amont de mon NAS sur mon réseau ?

C’est possible, mais malheureusement je n’ai plus de RT pour faire de test.

il y a 42 minutes, TuringFan a dit :

Je ne maitrise pas ces sujets mais est-il possible d'améliorer la sécurité de cette configuration (chiffrement dossier partagé + protocole HTTPS) ?

C’est une communication localhost, donc pas grand risque, maintenant si tu as peur qu’un autre docker sur le bridge snif les échanges, tu peux isolé le docker dans un autre bridge à part.

Rien ne t’empêche non plus d’utiliser un dossier chiffré pour stocker le dossier acme, mais la c’est plus contre les attaques physiques sur ton nas, le certificat n’a qu’une validé de 3 mois et il est révocable.

il y a 45 minutes, TuringFan a dit :

Une autre question naïve mais comment désactiver un jeu de clés API chez OVH ?

Fait une recherche sur les topics traitant de acme, on a déjà abordé le sujet avec détail (le mien ou cela oracle je ne sais plus)

il y a 47 minutes, TuringFan a dit :

Pourrais-je me utiliser le même certificat ?

Oui, mais autant lui mettre docker et son propre certificat en déploiement automatique, bien plus simple.

[TuringFan]

Merci @Einsteinium

[_DR64_]

Bonjour @Einsteinium,
Je viens d'avoir ça comme log cette nuit :

Citation

Tâche : Acme
Heure de début : Tue, 20 Sep 2022 05:00:01 GMT
Heure d'arrêt : Tue, 20 Sep 2022 05:00:09 GMT
État actuel : 0 (Normal)
Sortie/erreur standard :
Error response from daemon: Get "https://registry-1.docker.io/v2/": x509: certificate is valid for *.helpapp.io, not registry-1.docker.io
Acme
Acme
Total reclaimed space: 0B
8bf598695551291d9917976081d2907dd9911664093d9090f64d69e8c3aea900

C'est normal ?
Merci !

[Einsteinium]

Une erreur de certificat côté serveur docker 😉

[_DR64_]

Ok je touche à rien alors 😛 Merci !

[TuringFan]

Le 11/10/2020 à 12:58, Einsteinium a dit :

 

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

On remplit donc le formulaire, pour "Validity" (1) on choisit "Unlimited", pour "Rights" (2) on remplace dans les champs "mydomain.com" par le vôtre et dans "Restricted IPs" (3), on rajoute son IP afin qu'en cas de vol des clés, elles ne puissent être exploitées et votre domaine détourné. (NB : Si vous n'avez pas une IP fixe, on passe ce dernier point)

Bonjour @Einsteinium,

Désolé de t'embêter avec ça mais j'ai cherché sans trouver de solution (y compris du support OVH qui ne s'occupe pas des sujets API) : comment supprimer des clés API chez OVH ? J'en ai créé deux par erreur.

Cordialement,

[oracle7]

@TuringFan

Bonjour,

Supprimer des clés API :

• Se connecter sur OVH ici : https://api.ovh.com/console/ (avec le compte -ovh, pas l'@eMail)

• Aller sur : https://api.ovh.com/console/#/me/api/application#GET et cliquer sur le bouton « execute »

• On obtient la liste des ID d’applications API déjà créées

• Dans https://api.ovh.com/console/#/me/api/application/%7BapplicationId%7D#GET saisir/coller l’ID dans le champ « applicationId » puis « execute »

• Pour supprimer l’application : aller dans : https://api.ovh.com/console/#/me/api/application/%7BapplicationId%7D#DELETE et saisir/coller l’ID dans le champ « applicationId » puis « execute ».

 Cordialement

oracle7😉

 

[oracle7]

@Einsteinium

Bonjour,

Après avoir fait une installation "fraiche" de DSM7 sur un NAS d'un ami, j'ai pu créer sans problème un certificat LE mais lorsque je lance le deploy je récolte systèmatiquement une erreur d'authentification. J'ai pourtant bien créé un utilisateur spécifique tel qu'indiqué dans le TUTO et x fois vérifié son password (même testé avec et sans caractères spéciaux).

• username : AcmeDocker
• password : Xxx9xx$xxxxXxx0xx$

root@MonNAS:/volume1/docker/scripts_install/acme# docker exec Acme sh -c "acme.sh --deploy -d 'ndd.fr' --deploy-hook synology_dsm"
[Wed Oct 26 19:17:56 UTC 2022] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 7
[Wed Oct 26 19:17:56 UTC 2022] Logging into 172.18.0.2:5000
[Wed Oct 26 19:17:56 UTC 2022] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 7
[Wed Oct 26 19:17:56 UTC 2022] Unable to authenticate to 172.18.0.2:5000 using http.
[Wed Oct 26 19:17:56 UTC 2022] Check your username and password.
[Wed Oct 26 19:17:56 UTC 2022] If two-factor authentication is enabled for the user, set SYNO_TOTP_SECRET.
[Wed Oct 26 19:17:56 UTC 2022] Error deploy for domain:ndd.fr
[Wed Oct 26 19:17:56 UTC 2022] Deploy error.

Sinon pas de 2FA pour l'utilsateur qui déploie, depuis le NAS en SSH, je ping sans problème le conteneur 172.18.0.2 et le réseau bridge du conteneur semble correct :

root@MomNAS:/volume1/docker/scripts_install/acme# docker inspect synology-network
[
    {
        "Name": "synology-network",
        "Id": "2a969450a3140d78e785cc887066eb2fc94a11cffb383b23b6f260dda1f6fd38",
        "Created": "2022-10-26T14:58:26.87054153+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/24",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "a3b329fc53b64b1a6ec034a7d1bca4c2bea44a36fdbbe4f94dadbe04ad15779d": {
                "Name": "Acme",
                "EndpointID": "83bdf0820ac5f1dd8b2f19b7a806786b490ef246bc516066d1c5d343e225c2e3",
                "MacAddress": "d2:ca:ab:cd:18:02",
                "IPv4Address": "172.18.0.2/24",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.name": "br-synology"
        },
        "Labels": {}
    }
]

A noter aussi que contrairement à une installation précédente sur une autre machine, le fichier http.header reste vide. Y-a-t-il un rapport ? En tous cas, il y a sûrement un problème aussi de ce coté là. Mais là aussi je sèche ...

J'ai peut-être omis ou mal paramétré quelque chose dans DSM7 mais je ne vois pas quoi ni où.

Je tourne donc en rond à chercher d'où pourrait venir ces problèmes (mais surtout le premier).

Auriais-tu SVP une éventuelle piste/idée à m'indiquer ?

Cordialement

oracle7😉

Modifié le 26 octobre 2022 par oracle7

[oracle7]

@Einsteinium

Bonjour,

Finalement j'ai trouvé !

En fait, ce qui correspond au point B) 2) du TUTO, j'ai renommé toutes les variables d'environnement SAVED_SYNO_xxxx en SYNO_xxxx tout simplement et là aucun soucis le deploy s'est effecté correctement :

root@MomNAS:/volume1/docker/scripts_install/acme# docker exec Acme sh -c "acme.sh --deploy -d 'ndd.fr' --deploy-hook synology_dsm"
[Thu Oct 27 13:16:13 UTC 2022] Logging into 172.18.0.1:5000
[Thu Oct 27 13:16:14 UTC 2022] Getting certificates in Synology DSM
[Thu Oct 27 13:16:14 UTC 2022] Generate form POST request
[Thu Oct 27 13:16:14 UTC 2022] Upload certificate to the Synology DSM
[Thu Oct 27 13:17:34 UTC 2022] http services were restarted
[Thu Oct 27 13:17:34 UTC 2022] Success

Le log :

[Thu Oct 27 13:16:12 UTC 2022] Running cmd: deploy
[Thu Oct 27 13:16:12 UTC 2022] Using config home:/acme.sh
[Thu Oct 27 13:16:12 UTC 2022] default_acme_server='https://acme-v02.api.letsencrypt.org/directory'
[Thu Oct 27 13:16:12 UTC 2022] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Thu Oct 27 13:16:12 UTC 2022] DOMAIN_PATH='/acme.sh/ndd.fr'
[Thu Oct 27 13:16:12 UTC 2022] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh'
[Thu Oct 27 13:16:12 UTC 2022] _cdomain='ndd.fr'
[Thu Oct 27 13:16:12 UTC 2022] SYNO_Certificate='Certif_Acme_LE_Docker'
[Thu Oct 27 13:16:12 UTC 2022] _base_url='http://172.18.0.1:5000'
[Thu Oct 27 13:16:12 UTC 2022] Getting API version
[Thu Oct 27 13:16:12 UTC 2022] GET
[Thu Oct 27 13:16:12 UTC 2022] url='http://172.18.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth'
[Thu Oct 27 13:16:12 UTC 2022] timeout=
[Thu Oct 27 13:16:12 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header  -L '
[Thu Oct 27 13:16:13 UTC 2022] ret='0'
[Thu Oct 27 13:16:13 UTC 2022] Logging into 172.18.0.1:5000
[Thu Oct 27 13:16:13 UTC 2022] POST
[Thu Oct 27 13:16:13 UTC 2022] _post_url='http://172.18.0.1:5000/webapi/auth.cgi?enable_syno_token=yes'
[Thu Oct 27 13:16:13 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header  -L '
[Thu Oct 27 13:16:14 UTC 2022] _ret='0'
[Thu Oct 27 13:16:14 UTC 2022] token='TrAwA6QSsGyBc'
[Thu Oct 27 13:16:14 UTC 2022] Getting certificates in Synology DSM
[Thu Oct 27 13:16:14 UTC 2022] POST
[Thu Oct 27 13:16:14 UTC 2022] _post_url='http://172.18.0.1:5000/webapi/entry.cgi'
[Thu Oct 27 13:16:14 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header  -L '
[Thu Oct 27 13:16:14 UTC 2022] _ret='0'
[Thu Oct 27 13:16:14 UTC 2022] escaped_certificate='Certif_Acme_LE_Docker'
[Thu Oct 27 13:16:14 UTC 2022] Generate form POST request
[Thu Oct 27 13:16:14 UTC 2022] Upload certificate to the Synology DSM
[Thu Oct 27 13:16:14 UTC 2022] POST
[Thu Oct 27 13:16:14 UTC 2022] _post_url='http://172.18.0.1:5000/webapi/entry.cgi?api=SYNO.Core.Certificate&method=import&version=1&SynoToken=TrAwA6QSsGyBc&_sid=KSGjwX7bQHU3cFrm0CT0rxUJyKm5ArjSKX9sdS2SMscAvKAj8qQFevPpUAMQ98zoxjD7NFd3nIfM7t2-Rh1hAQ'
[Thu Oct 27 13:16:14 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header  -L '
[Thu Oct 27 13:17:34 UTC 2022] _ret='0'
[Thu Oct 27 13:17:34 UTC 2022] http services were restarted
[Thu Oct 27 13:17:34 UTC 2022] Success

Et au passage le fichier "http.header" a bien été lui aussi renseigné.

 

Du coup, le point B) 2) serait-il erroné ? Ton avis STP ?

Pour moi oui, dans la mesure où le script acme.sh attend des variables d'environnement bien spécifiques nommées SYNO_xxxxx pour son exécution et pas leurs sauvegardes SAVED_SYNO_xxxxx qui au passage non pas été réécrites dans le fichier account.conf à l'issue du déploiement.

Maintenant, ce qui m'échappe c'est que d'autres ont suivi ce TUTO et n'ont pas rencontré, du moins pas remonté, cette anomalie ?????

Cordialement

oracle7😉

Modifié le 27 octobre 2022 par oracle7

[Einsteinium]

@oracle7 Désolé pas vue la notification (mail encore en spam 🙃)

Alors j’ai été voir dans le doute mes configuration, mon certificat ayant été renouvelé y a peu, les variables sont toujours bien tel que dans le tutoriel, pas eu de migration, il y a peu être eu un update depuis peu qui ne me touche pas étant sous l’ancien régime… c’est à approfondir du coup.

[Mic13710]

Le 27/10/2022 à 15:35, oracle7 a dit :

au point B) 2) du TUTO, j'ai renommé toutes les variables d'environnement SAVED_SYNO_xxxx en SYNO_xxxx tout simplement et là aucun soucis le deploy s'est effecté correctement :

et @Einsteinium. Je viens de faire le déploiement sur mon 220+. J'ai plus ou moins suivi le tuto (j'ai 2 ndd dans la même instance Docker, ce qui complique un peu la tâche) et SAVED_SYNO a fonctionné sans problème. Bizarre qu'il t'ai fallu modifier ces lignes.

[Einsteinium]

@Mic13710 merci pour le retour 🙂

Tu as mis les deux ndd directement sur le même certificat rassure moi ?