La connexion Facebook a été signalée comme non conforme par Facebook après le changement vers le système de certificat Let's Encrypt

Soutien
1

Depuis environ le 30 septembre 2021 (autant que je puisse en juger), mon site génère des erreurs de certificat :

Votre connexion n’est pas privée
Avertissement de sécurité « NET::ERR_CERT_COMMON_NAME_INVALID ».

Ce serveur n’a pas pu prouver qu’il s’agit de www.nzarchitecture.net.nz ; son certificat de sécurité provient de nzarchitecture.net.nz. Cela peut être dû à une mauvaise configuration ou à une interception de votre connexion par un attaquant.

Ce problème pourrait être lié aux modifications mises en œuvre par Let’s Encrypt à cette date.
Le problème se déclenche lorsque l’URL https://www.nzarchitecture.net.nz est utilisée, mais pas lorsque https://nzarchitecture.net.nz est utilisée.

Le problème persiste même après la mise à jour vers la version 2.8.0 bêta 7 et la reconstruction complète.

Une conséquence de l’apparition de ce message d’erreur sur ma page d’accueil est que le site est signalé comme ne répondant plus aux exigences de Facebook, ce qui a entraîné la désactivation de la connexion Facebook par Facebook.

1 « J'aime »
2

C’est un problème Facebook qu’ils doivent résoudre.

Le certificat est 100 % légitime.

1 « J'aime »
3

Cela semble similaire à…
https://meta.discourse.org/t/configuring-google-login-for-discourse/15858/239

1 « J'aime »
4

Le problème, c’est que même moi, je vois ces erreurs lorsque j’inclus « www » dans l’URL que je colle ou saisis dans le navigateur. Donc, même s’il n’y a aucun risque réel, les utilisateurs se voient confrontés à des avertissements inquiétants, avec ou sans le problème de conformité Facebook.

Facebook, quant à lui, refuse d’examiner la question tant que l’erreur n’a pas disparu.

5

dans votre fichier de configuration

/var/discourse/containers/app.yml

à quoi est défini DISCOURSE_HOSTNAME: ?

1 « J'aime »
6

Si votre véritable site se trouve sous le domaine sans « www », vous devez enregistrer ce domaine non-www dans le système Facebook. Il n’est pas possible de mélanger les deux.

4 « J'aime »
7

app.yml indique

DISCOURSE_HOSTNAME : nzarchitecture.net.nz

8

D’accord, je suppose que cela a du sens. Mais d’un point de vue DNS, l’un est un alias de l’autre (du moins c’est ce que je croyais). Il sera difficile d’expliquer à l’utilisateur moyen qu’il ne peut pas utiliser « www », surtout s’il doit se connecter pour voir un avertissement à cet effet…

1 « J'aime »
9

Ce n’est pas vraiment un « alias », mais une redirection. Vous devez configurer correctement une redirection, ce qui implique d’avoir un certificat en place pour l’endroit où réside la redirection.

Par exemple, nos partenaires chez communiteq proposent un service à cette adresse : https://www.forcewww.com/

4 « J'aime »
10

Jusqu’à récemment, cela n’avait jamais posé de problème : aucun avertissement de Facebook et aucun avertissement de certificat, avec ou sans « www ».

Existe-t-il un moyen d’obtenir que le certificat Let’s Encrypt gratuit par défaut certifie les deux options ? Je tiens à ne pas compliquer les choses avec des certificats supplémentaires à gérer et des coûts supplémentaires.

Il existe de nombreux e-mails contenant des liens vers le site incluant le « www ».

Par « l’endroit où réside la redirection », voulez-vous dire Digital Ocean dans ce cas ? (mon hébergeur, et l’endroit où les paramètres DNS sont gérés)

11

Vous pouvez ajouter une ou deux lignes supplémentaires à votre fichier app.yml. Cela a fonctionné pour moi lorsque j’avais des problèmes :

4 « J'aime »
12

Merci – cela semble prometteur.

Dans mon cas, si https://nzarchitecture.net est le nom de domaine de base, les lignes correctes à ajouter seraient-elles les suivantes ?

after_ssl:
- replace:
filename: “/etc/runit/1.d/letsencrypt”
from: /–keylength/
to: “-d www.nzarchitecture.net.nz --keylength”

Et dois-je reconstruire Discourse pour que cela prenne effet ?

13

Le contenu est correct, mais l’indentation est importante dans le fichier yml, ce qui doit donc être corrigé :

  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d www.nzarchitecture.net.nz --keylength"

Vous devrez reconstruire pour que cela prenne effet.

Édition : En fait, il semble que l’utilisation de --keylength ait été remplacée par -k, vous aurez donc besoin de ce qui suit à la place :
Désolé, ma recherche sur Github m’a conduit à une ancienne fourche sans que je ne le remarque. --keylength est correct.

5 « J'aime »
14

Fantastique ! Merci beaucoup pour votre aide @Simon_Manning et à tous — ce redirigement via app.yml a parfaitement fonctionné.

2 « J'aime »
15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.