Avatars, logos de site et erreurs de certificat

[markcichy (Mark)]

Voici un lien vers l’une des instances :
https://discourse.mobiusnode.io

Elle est hors ligne. X-Forwarded-Proto est présent dans mon bloc de serveur. Ainsi, le seul élément (ou les seuls éléments) que je n’utilise pas — d’après les liens que vous avez tous partagés — est le suivant :

# modèles de base utilisés ; peut être réduit pour inclure moins de fonctionnalités par modèle de conteneur :
# - "templates/cron.template.yml" # cron est désormais inclus dans l'image de base
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # supprimer - https sera géré par nginx externe
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- Ajouté
# quels ports exposer ?
# expose : commenter toute la section

[itsbhanusharma (Bhanu Sharma)]

J’ai chargé le site sur trois navigateurs (Edge, Firefox et Chrome mobile) et j’obtiens un certificat parfaitement valide en mode anonyme. Quelles sont vos étapes pour reproduire ce problème ?

[markcichy (Mark)]

Inscrivez-vous en tant qu’utilisateur. Une fois inscrit et connecté, tout s’emballe et je rencontre les erreurs mentionnées précédemment.

[itsbhanusharma (Bhanu Sharma)]

Ok, je vais m’inscrire en tant qu’utilisateur fictif via Firefox maintenant.

[itsbhanusharma (Bhanu Sharma)]

Vos e-mails n’arrivent jamais dans ma boîte de réception. J’ai essayé de les renvoyer, mais sans succès. Activez-vous simplement les comptes manuellement ici ?

[markcichy (Mark)]

Non. Ils ont probablement atterri dans les courriers indésirables ou les spams. Aucun utilisateur ne s’est plaint à ce sujet.

[itsbhanusharma (Bhanu Sharma)]

L’enfer ne s’est pas déchaîné ici. Un problème potentiel est que vos e-mails contiennent toujours le lien http://. Cependant, j’ai été correctement redirigé vers le site en https pour activer mon compte et je ne vois aucune erreur liée à SSL ici.

Donc oui, je suis à 99 % sûr que votre force_https n’est pas activé ou qu’il y a quelque chose de très très grave dans votre installation qui cause cela.

[markcichy (Mark)]

J’ai une redirection dans mon bloc de serveur, donc peu importe quel lien y est affiché. Il sera toujours redirigé vers https.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

peu importe quel lien y est affiché

C’est là que vous vous trompez. Si le forçage du HTTPS est activé, Discourse doit envoyer tous les liens en HTTPS. Chaque lien lié au forum doit être chargé via HTTPS. Si vous continuez à faire des choses étranges et à ne pas suivre la méthode recommandée, c’est à vos risques et périls. Nous ne pouvons pas aller au-delà des procédures standard qui fonctionnent.

[markcichy (Mark)]

Cela n’a pas beaucoup de sens pour moi. Si on décompose cela logiquement, je fais essentiellement exactement ce que force-https est censé faire, mais au niveau du bloc serveur.

[markcichy (Mark)]

De plus, lorsque j’active force-https, mon site ne fonctionne plus et les utilisateurs ne peuvent plus s’authentifier.

[itsbhanusharma (Bhanu Sharma)]

force_https n’est pas simplement une réécriture. Il fait plus que cela en interne. Si vous souhaitez que vos problèmes soient résolus, une solution a déjà été fournie. Si vous refusez cette solution, n’hésitez pas à prendre les choses en main et à explorer de nouvelles pistes.

@markcichy

En outre, lorsque j’active force-https, mon site ne fonctionne plus et les utilisateurs ne peuvent pas s’authentifier.

Cela est dû à votre proxy inverse instable. Vous devrez identifier ce qui ne va pas et agir de manière appropriée. Nous ne pouvons pas fournir d’assistance concernant vos propres solutions.

[markcichy (Mark)]

Toutes les « solutions » présentées ne correspondent pas à mon cas d’usage spécifique :

• Serveur distant (au sein du même réseau) — Je pense que tous les exemples supposent que Nginx s’exécute sur le même serveur que Discourse ; j’utilise proxy_pass pour accéder à une autre adresse IP interne.

Pourquoi ai-je fait cela ? Pour une sécurité accrue et une répartition des ressources. C’est la même raison pour laquelle je sépare les services de deux manières : par conteneur et par machine virtuelle. Les documents suggérés semblent privilégier un scénario où tous les services s’exécutent sur le même serveur.

Je suppose que les conditions décrites ci-dessus sont assez courantes. Si l’une d’elles peut être utilisée pour prendre en charge une configuration proxy_pass, je suis tout à fait disposé à adapter mes paramètres en conséquence. Je trouve simplement que fournir une déclaration générale du type « vous êtes seul » parce que j’essaie d’éviter de « mettre tous mes œufs dans le même panier » est quelque peu injustifié.

[itsbhanusharma (Bhanu Sharma)]

proxy_pass 192.168.20.10:8080

dans Discourse, exposez 192.168.20.10:8080:80

supprimez le modèle socketé.

activez force_https

C’est gagné.

[markcichy (Mark)]

Cela a toute une série d’implications au-delà de ce que vous venez d’écrire, que je devrai investiguer — nous aurions pu commencer par là.

Questions immédiates :

1. Dans app.yml, changer le port d’écoute par défaut en 8080 ?
2. Que faire pour SSL 443 ? Laisser 443 ?
3. Supprimer la redirection sur 80 dans le bloc de serveur Nginx ?
4. Est-ce que le point #3 a de l’importance si je modifie simplement le proxy_pass côté interne ? Probablement pas ? Je me contente de réacheminer vers 8080 ?
5. La plus grande question : pourquoi ? Pourquoi cela ferait-il une différence de passer de 80 à 8080 ?
6. Conserver tous les autres Templates actifs ? Juste commenter socketed ?

Merci pour votre aide et votre patience.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

Dans app.yml, changer le port d’écoute par défaut en 8080 ?

C’est votre préférence, je l’ai écrit à titre d’exemple. Vous pouvez également choisir d’exposer le port 80.

@markcichy

Et SSL 443 ? Garder le 443 ?

Il n’y a aucun avantage ni intérêt à activer SSL sur un réseau local.

@markcichy

Supprimer la redirection sur le port 80 depuis le bloc serveur Nginx ?

Cela doit rester en place.

server {
    listen 80;
    server_name discourse.example.com;
    return 301 https://example.com$request_uri;
}

@markcichy

Est-ce que le point #3 a de l’importance si je change simplement le proxy_pass côté interne ? Probablement pas ? Je fais juste du routage vers le port 8080 ?

C’est exactement ce qui se passe : vous redirigez toutes les requêtes reçues par votre proxy/ingress vers un backend interne sur le port 8080 (c’est-à-dire Discourse).

@markcichy

La plus grande question : pourquoi ? En quoi cela ferait une différence de passer du port 80 au 8080 ?

Répondu en #1 : c’était une préférence personnelle, n’hésitez pas à utiliser le port qui vous convient.

@markcichy

Garder tous les autres Templates actifs ? Juste commenter socketed ?

Vous n’avez particulièrement besoin de rien lié aux sockets ou à SSL sur le serveur interne. SSL doit être correctement terminé au niveau du reverse-proxy.

NB : la plupart de ces choix sont des préférences personnelles basées sur un déploiement destiné à des clients.

[markcichy (Mark)]

D’accord. Merci pour vos commentaires.

Voici mon bloc de serveur Nginx, pour information :

server {
# ssl
listen 443 ssl http2;
listen [::]:443 ssl http2;

    server_name discourse.mobiusnode.io;

    location / {
            # trafic http
            proxy_pass http://192.168.86.108;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Host $http_host;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";

    }

`ssl on;`
`ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # géré par Certbot`
`ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # géré par Certbot`

`ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';`
`ssl_protocols TLSv1.2;`
`ssl_prefer_server_ciphers on;`
`ssl_session_cache shared:SSL:10m;`

`add_header Strict-Transport-Security "max-age=63072000;";`
`ssl_stapling on;`
`ssl_stapling_verify on;`

`client_max_body_size 0;`

}

server {
if ($host = discourse.mobiusnode.io) {
return 301 https://$host$request_uri;
} # géré par Certbot

listen 80;
listen [::]:80;

server_name discourse.mobiusnode.io;
return 404; # géré par Certbot

}

[markcichy (Mark)]

Le comportement que je rencontre se produit dans les conditions mentionnées ci-dessus.

Le début du fichier app.yml ressemble à ceci :

## Ceci est le modèle de conteneur Docker Discourse tout-en-un et autonome
##
## Après avoir apporté des modifications à ce fichier, vous DEVEZ reconstruire
## /var/discourse/launcher rebuild app
##
## SOYEZ TRÈS PRUDENT LORS DE LA MODIFICATION !
## LES FICHIERS YAML SONT EXTRÊMEMENT SENSIBLES AUX ERREURS D'ESPACEMENT OU D'ALIGNEMENT !
## Visitez http://www.yamllint.com/ pour valider ce fichier si nécessaire

templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Décommentez ces deux lignes si vous souhaitez ajouter Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

## Quels ports TCP/IP ce conteneur doit-il exposer ?
## Si vous souhaitez que Discourse partage un port avec un autre serveur web comme Apache ou nginx,
## consultez https://meta.discourse.org/t/17247 pour plus de détails
expose:
- "80:80" # http
- "443:443" # https

params:
db_default_text_search_config: "pg_catalog.english"

## Définissez db_shared_buffers à un maximum de 25 % de la mémoire totale.
## Sera défini automatiquement par bootstrap en fonction de la RAM détectée, ou vous pouvez le remplacer
db_shared_buffers: "1024MB"

## Peut améliorer les performances de tri, mais augmente l'utilisation de la mémoire par connexion
#db_work_mem: "40MB"

## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : tests-passed)
#version: tests-passed

[RGJ (Richard - Communiteq)]

Vous vous connectez au port 80 sur le deuxième nginx, ce qui lui fait croire que vous vous connectez en http et non en https.

Essayez de trouver X-Forwarded-Proto dans le nginx interne et remplacez proxy_set_header X-Forwarded-Proto $thescheme; par proxy_set_header X-Forwarded-Proto https;

ou redirigez votre trafic vers https proxy_pass https://192.168.86.108

[itsbhanusharma (Bhanu Sharma)]

@markcichy

- "80:80" # http
- "443:443" # https

Cette partie doit être modifiée