TuringFan

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

Merci @oracle7 et @Jeff777, Pour faire les choses correctement cette fois-ci comment dois-je m'y prendre ? Désinstaller acme.sh : si oui comment faire ? Supprimer les fichiers : si oui lesquels ?§ Reprende le tuto sur les parties 2, 4 et 5 ? Ai-je oublié quelque chose ?

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

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

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

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 ... Non pas encore passé sur DSM 7.0 : preneur d'ailleurs d'un lien pour les bonnes pratiques / pièges à éviter. 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 ... 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,

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

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,

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,

Lol je prends le point. Sinon @maxou56 m'a expliqué que dans ce cas besoin d'un couple identifiant / mdp d'un utilisateur admin ou des cles de chiffrement des dossiers (si migration, reset, etc.)

Très clair merci

J'utilise également pour des snapshot. je crois comprendre (sans maitriser) que les snapshots sont également sauvegardés lors des sauvegardes Hyper Backup. Merci encore oour tes réponses.

Sous l'hypothèse que le malfaiteur dispose d'un temps important sur le site, peut il opérer pour lire des données sans déconnecter le NAS de son alimentation ? C'est un cas bien plus théorique que réaliste je pense mais il me permet de parfaire mes connaissances NAS.

OK, merci. @maxou56 j'imagine que tu utilises Hyper Backup pour tes sauvegardes croisées ?

Ok merci @oracle7. A titre perso mon LAN est en 192. et mon VPN en 172. Impossible donc d'imposer au NAS des connexions physiques sur une classe spécifique comme on peut le faire ed faon analogue avec le DHCP ? C'est bien mon cas, un mdp de 114 bits. Merci @maxou56, Quid du cas des dossiers partagés chiffré mais montés au moment de l'attaque en physique ?

Ok merci,

Merci @maxou56 pour tes réponses, Ok donc en gros : Pour un NAS principal, chiffrer ses dossier partagés est une condition suffisante pour empêcher une lecture par un accès malveillant en physique ? M^mee si les dossiers partagés sont montés ? Pour un NAS secondaire (de sauvegarde), chiffrer la sauvegarde (mais pas les dossiers partagés) est une condition suffisante pour empêcher une lecture par un accès malveillant en physique ? Même si une sauvegarde : synchronisation est en cours ? Aucune règle spéciale pour des "IP physique" n'est utile pour le pare feu ? Pour le transfert quel est le plus intéressant en terme de sécurité / performance : le chiffrement hyper backup ou le VPN ? Un intérêt de cumulé les deux ?

Merci @oracle7 pour ta réponse, Je me demandais s'il y avait des choses à faire coté pare feu : les IPs LAN branchées en physique (ethernet / usb) ont-elles un format spécifique ? Rien de tel en dehors de ma recette du gâteau au chocolat lol. Je pensais par exemple à un accès root et/ou en utilisant les services de fichiers tels que SMB, CIFS, AFP, NFS, FTP, TFTP, rsync, etc. Ok, Merci

Merci @.Shad., c'est malheureusement explicite ... DSM 7 change -t-il quelque chose à cela ?

Bonjour à tous, Un upgrade vers DSM 7 change-t-il / simplifie-t-il l'implémentation d'une stratégie de sauvegarde double NAS telle que décrite dans premier post de ce fil ? Merci d'avance,

Bonjour à tous, J'ai deux questions : 1 - Quelle serait les capacités d'une personne malveillante si elle parvenait à se connecter physiquement (via un cable Ethernet ou USB) à un NAS (sans connaitre les logins) ? Comment se prémunir des éventuels risques liés à ce comportement ? J'ai posté ici à ce sujet. 2 - Y a t il des actions (en terme de sécurisation de son NAS) spécifiques à effectuer lors d'un upgrade vers DSM 7 si on a déjà suivi ce tuto sous DSM 6 ? Merci d'avance,

Bonjour @oracle7, J'ai cru comprendre que DSM 7.0 facilitait la gestion des certificats : un intérêt de migrer dans le cadre du sujet de ce fil ? Bonne journée,

Bonjour à tous, Ma configuration J'utilise File Station, Drive et Moment sans problème en passant systématiquement via des reverser proxy qui entrent par le port 443 et pointent ensuite vers des ports http. Je peux donc atteindre mes applications avec des adresses du type https://application.ndd.tld depuis des IP LAN, VPN et WAN (sauf pour File Station). Dans le menu avancé de la section accès externe du panneau de configuration j'ai : Nom de l’hôte : files.ndd.tld DSM (HTTP) : vide DSM (HTTPS) : 443 Comportement actuel Aujourd'hui lorsque je souhaite partager un fichier via un lien cela dépend de l'application. Via Drive (via navigateur ou application smartphone) Le lien généré est de la forme : https://drive.ndd.tld/x/y/123456789012345678 le partage peut se faire vers des users NAS seulement le partage peut être public le téléchargement est blocable un mot de passe peut être demandé une date d'expiration peut être ajoutée N'importe quel appareil en LAN, VPN ou WAN semble pouvoir accéder au fichier. Via Moment (via navigateur ou application smartphone) Le lien généré est de la forme : https://files.ndd.tld:X/mo/sharing/A2b4c5d6e7f9 [le nom de domaine correspond au paramétrage du nom d'hôte dans le menu accès interne (cf. précédemment) et X est le port HTTP vers lequel le reverse proxy de l'application moment pointe] le partage ne peut pas se faire vers des users NAS seulement le partage peut être public le téléchargement est blocable un mot de passe peut être demandé une date d'expiration peut être ajoutée En l'état aucun appareil en LAN, VPN ou WAN ne semble pouvoir accéder au fichier : il faut modifier le lien en remplaçant files.ndd.tld:X/ par photo.ndd.tld/ (ce qui correspond à l'adresse utilisée pour atteindre moment avec le reverse proxy). Avec cette modification qui doit être systématique et manuelle le fichier est accessible depuis un appareil en LAN, VPN ou WAN. Via File Station (uniquement via navigateur) Le lien généré est de la forme : https://files.ndd.tld/sharing/A2b4c5d6e7f9 [le nom de domaine correspond au paramétrage du nom d'hôte dans le menu accès interne (cf. précédemment)] le partage peut se faire vers des users NAS seulement le partage peut être public le téléchargement est blocable un mot de passe peut être demandé une date d'expiration peut être ajoutée un nombre limite d'accès peut être paramétré N'importe quel appareil en LAN, VPN ou WAN semble pouvoir accéder au fichier. Via File Station (uniquement via l'application smartphone) Le lien généré est de la forme : https://files.ndd.tld/sharing/A2b4c5d6e7f9 [le nom de domaine correspond au paramétrage du nom d'hôte dans le menu accès interne (cf. précédemment)] le partage peut se faire vers des users NAS seulement le partage peut être public le téléchargement est blocable un mot de passe peut être demandé une date d'expiration peut être ajoutée un nombre limite d'accès peut être paramétré N'importe quel appareil en LAN, VPN ou WAN semble pouvoir accéder au fichier. Mon besoin In fine je voudrais savoir comment avoir un comportement uniforme avec mes différentes applications (via application smartphone et/ou via navigateur) : notamment (i) ne pas avoir à manuellement modifier le lien généré par moment et (ii) permettre de gérer les droits associés au liens (utilisateurs NAS et/ou public, téléchargement blocable, mot de passe, date d'expiration, nombre limite d'accès, etc.). Savez-vous comment faire ? Peut-être utiliser les fonctions d'alias personnalisé et/ou de domaine personnalisé dans le portail des application ? Mais je reconnais volontiers que je ne comprend pas bien ces notions (surtout vs. un reverse proxy). Peut être sinon qu'une migration DSM 7.0 résoudra ce problème ? Mais j'appréhende un peu cette opération (peur que ce soit plus complexe qu'annoncé et/ou de perdre des fonctionnalités / applications) : je vais regarder les sujets des dockers avant (que je ne maitrise pas). Enfin c'est un autre sujet pour une prochaine fois. Merci d'avance pour votre aide,

@oracle7 et @Mic13710 merci je vais essayer dès que j'ai un peu de temps.

Merci @Mic13710, Concrètement dois-je reprendre la totalité du tuto ou y a t il que quelques manip à passer pour changer l'utilisateur ? Qu'est ce que le fail2ban ? Merci,