Que dit le fichier log/production.log (dans le Docker en cours d’exécution) lorsque vous tentez de vous connecter avec un échec (donc avec force_https=true) ?
@RGJ – J’apprécie ta solution ! Dois-je forcer le HTTPS avec la dernière suggestion ? RE proxy_pass https.
MODIF : J’obtiens une erreur 502 si je me contente d’utiliser proxy_pass https://192.168.86.108.
MODIF2 : J’ai désactivé le port 80 sur Discourse via app.yml et cela ne fonctionnait toujours pas. Je viens de relire ton message : le conteneur Discourse possède-t-il sa propre instance de Nginx ? En somme, est-ce que je configure un proxy vers un autre proxy ? Désolé, je suis vraiment perdu à ce stade.
@itsbhanusharma Dois-je commenter 80:80 #http et suivre le conseil de @RGJ pour utiliser proxy_pass https ?
Pourquoi ne suivez-vous pas ici la procédure prise en charge pour les multisites ? Vous réinventez en réalité une roue très fragile.
Autant de liens ont été fournis maintenant, @Stephen, que je suis perdu et ne parviens pas à y voir clair. Je croyais suivre les processus pris en charge. Les commentaires ci-dessus ne le sont-ils pas ? 
Oui, car vous n’utilisiez pas force_https, d’où le tag unsupported-install ci-dessus. Si vous vous écartez d’une prise en charge officielle, vous ne recevrez que peu d’aide.
Commencez ici :
Il existe un guide séparé pour gérer l’encapsulation SSL avec plusieurs sites.
Donc, le conteneur standard exécute-t-il uniquement http ? En quoi ce que j’essaie de faire est-il multi-sites ? Je n’essaie pas d’héberger plusieurs domaines ; j’ai un seul domaine. Pouvez-vous s’il vous plaît clarifier comment cela répond à mon problème ?
Que voulez-vous dire par :
J’ai configuré des serveurs Discourse sur environ 5 instances et elles semblent toutes présenter un comportement étrange ; je ne sais pas s’il s’agit vraiment d’un bug ou si d’autres ont rencontré le même problème.
Infrastructures indépendantes, en aucune façon connectées entre elles.
Mais toutes avec des paramètres très similaires comme indiqué ci-dessus.
Alors pourquoi nginx fait-il proxy pour l’hôte ? Que se passe-t-il d’autre sur les machines ?
Nous avons plusieurs VM qui ne sont pas exposées externement, le trafic est acheminé via le proxy (est exposé externement) vers la VM Discourse en interne. Situation similaire dans chacune des installations distinctes. Est-ce que cela clarifie ?
Pas vraiment, mais d’une manière ou d’une autre, c’est une contrainte technique avec laquelle vous devrez composer. Il est impossible de se prononcer sur l’existence d’une meilleure approche lorsque le cas d’usage et la topologie sont si ambigus.
Je pense que la bonne *combinaison de solutions était la suivante :
Selon @itsbhanusharma :
MODIFICATION /var/discourse/containers/app.yml et modification des ports vers des valeurs personnalisées ; j’ai utilisé :
- "8080:80" #http
- "4343:443" #https
J’ai exécuté ./launcher rebuild app.
J’ai ensuite modifié notre proxy accessible de l’extérieur pour qu’il redirige les requêtes sur les ports 80/443 vers http://ip_interne:8080.
Après avoir lancé sudo nginx -t et sudo systemctl restart nginx, je me suis connecté au serveur https://discourse.mobiusnode.io (qui présentait toujours les problèmes mentionnés ci-dessus) et j’ai activé l’option force_https. À ce stade, tout semble fonctionner.
Je vais maintenant reproduire cette procédure sur les autres serveurs/infrastructures.
Pour être clair, ce n’est pas ce que j’ai suggéré.
Je vous ai simplement demandé d’exposer le port 80 sur une adresse IP locale et de terminer le SSL sur votre proxy inverse.
Donc, ne pas utiliser SSL sur mon proxy exposé à l’extérieur, mais plutôt transférer des requêtes http en clair vers le serveur Discourse et laisser force_https gérer ces requêtes ? Comment le certificat est-il alors transmis ? Via la première instance Nginx ? C’est là que les choses se compliquent pour moi.
Eh bien, tant que cela fonctionne et que vous pouvez reconstruire/mettre à niveau proprement. Il semble que vous fassiez déjà ce que @itsbhanusharma a suggéré dans son dernier message.
Si vous partagez une seule adresse IP avec plusieurs connexions SSL, vous avez besoin d’un certificat SAN à l’entrée de votre proxy. Si le réseau est sécurisé, tout ce qui se trouve derrière peut être non chiffré.
Discourse nécessite force_https si l’utilisateur se connecte via SSL, et vous devez vous assurer que l’en-tête mentionné ci-dessus est préservé et transmis.
Non, il existe quelque chose appelé SNI (Indication du nom de serveur).
Je le sais très bien, mais puisque tous les certificats proviennent de Let’s Encrypt, quel intérêt y a-t-il à demander des certificats séparés ? Let’s Encrypt prend en charge les SAN, alors pourquoi ne pas les utiliser ?