J’ai actuellement le problème suivant et je serais vraiment heureux si quelqu’un pouvait m’aider à trouver la bonne approche.
J’ai installé Discourse sur un serveur Ubuntu 21.10 sur Vultr
J’ai utilisé la configuration par défaut et j’ai déjà créé un certificat Let’s Encrypt (pour www.example.com) lors de l’installation
Mon objectif est que mon forum ne soit accessible que via www → www.example.com et non example.com
Situation actuelle :
→ http://example.com redirige correctement (301) vers https://www.example.com
→ http://www.example.com redirige correctement (301) vers https://www.example.com
→ https://example.com génère une erreur de certificat et n’est pas redirigé vers le bon https://www.example.com (le certificat a été émis pour www.example.com et non pour example.com)
Quelle est la meilleure approche pour que https://example.com redirige vers https://www.example.com et comment puis-je atteindre mon objectif ?
C’est un domaine sur lequel je ne suis pas très calé. Quelle serait la méthode recommandée ? J’ai actuellement un enregistrement A pour le domaine et le sous-domaine www qui résolvent tous deux vers mon droplet Digital Ocean.
Merci beaucoup pour votre retour @JammyDodger. Je vais essayer, même si cela semble traiter un problème légèrement différent. Mais peut-être que cela fonctionnera.
Ce type de redirection est si trivial sur n’importe quel serveur web et une recherche sur Google révèle comment le faire. Pourquoi est-ce différent ici ?
Je suis à peu près certain que si vous demandez les deux certificats, cela redirigera comme vous le souhaitez. La solution forcewww.com est plus simple.
Parce que c’est à l’intérieur d’un conteneur Docker et qu’aucune des solutions internes à l’hôte que vous trouvez ailleurs ne sera probablement utile.
Juste une petite mise à jour pour vous faire savoir ce qui a fonctionné pour moi.
J’ai essayé, mais cela n’a pas fonctionné pour moi. Il semblait qu’aucun certificat supplémentaire n’ait été émis.
J’ai également essayé de résoudre mon problème en suivant cette suggestion, mais cela n’a pas non plus fonctionné pour moi.
La seule chose qui a résolu mon problème jusqu’à présent a été de suivre les instructions ici http://www.forcewww.com/
Néanmoins, je pense que ce n’est toujours pas une solution souhaitable, car elle repose sur un service externe. Bien sûr, c’est gratuit, mais vous devrez trouver une nouvelle solution une fois que ce service sera hors service.
J’espère que vous ne me comprenez pas mal @michaeld, c’est vraiment une solution agréable et facile que vous proposez et je l’apprécie beaucoup.
Ce serait une chose plutôt cool, si vous pouviez décider lors de l’installation standard de n’utiliser que la version www ou non www pour nous faciliter la vie un peu
Bien que je ne l’aie pas testé le mois dernier, je suis à peu près sûr que cela fonctionne. Si votre DNS n’était pas correctement configuré et que vous l’avez exécuté plusieurs fois, vous avez été limité par le débit.
Voulez-vous dire « et demander un certificat avec les deux noms d’hôte ? » C’est beaucoup trop difficile. La probabilité que cela casse des choses pour beaucoup de gens qui ne savent pas comment configurer le DNS de cette manière est très, très élevée.
Si vous créez un certificat pour la version apex et la version www, vous couvrirez les deux. :smiley Comme vous l’avez indiqué, le certificat n’inclut pas votre domaine apex… d’où l’erreur.
Ainsi, que quelqu’un tape le domaine apex ou la version www, il atterrira sur votre https://www.example.com sans aucune erreur. La meilleure pratique consiste à inclure à la fois l’apex et le www sur votre certificat. Assurez-vous simplement que votre certificat modifié/nouveau est celui servi par votre serveur, et non l’ancien.
Je vois. Et maintenant que vous le mentionnez, je commence à m’en souvenir — c’était la deuxième raison pour laquelle j’ai placé Discourse derrière un Nginx “normal”. La première raison était le besoin de faire un certain filtrage. Eh bien, ma solution n’est pas particulièrement sophistiquée ou techniquement exigeante, mais elle n’est pas très populaire dans ce cercle.
Je dois dire que Docker n’est pas une solution très conviviale si une chose aussi triviale doit être faite à l’aide d’un service Web tiers. Sinon, Docker doit être très utile, je suppose, à moins qu’il ne devienne aussi populaire.
Merci pour vos conseils @pfaffman. Je vais réessayer ce week-end.
Et à propos du deuxième sujet. Je vois votre point de vue, mais cela pourrait être une sorte de paramètre avancé ou optionnel, car il est vraiment crucial que le même contenu ne soit accessible que par un seul domaine.
En fait, ce n’est pas le cas (sauf si Discourse lui-même ne fonctionne pas). Mais si vous faites référence au SEO et à Google, un tel problème de sous-domaine n’est plus grave depuis longtemps. Google peut vivre avec cela, car il n’y a qu’un seul domaine — l’un est un FQDN de type stub et l’autre avec www est le vrai.
Quelle serait la méthode recommandée ? J’ai actuellement un enregistrement A pour le domaine et le sous-domaine www qui résolvent tous deux vers mon droplet Digital Ocean.