С non-www на www без ошибки сертификата

Привет, сообщество,

У меня возникла следующая проблема, и я был бы очень рад, если бы кто-то мог помочь мне найти правильное решение.

  1. Я установил Discourse на сервер Ubuntu 21.10 в Vultr.
  2. Использовал настройку по умолчанию и уже создал сертификат Let’s Encrypt (для www.example.com) в процессе установки.

Моя цель — сделать так, чтобы форум был доступен только через www —> www.example.com, а не через example.com.

Текущая ситуация:

  • http://example.com корректно перенаправляет (301) на https://www.example.com
  • http://www.example.com корректно перенаправляет (301) на https://www.example.com
  • https://example.com выдаёт ошибку сертификата и не перенаправляется на правильный адрес https://www.example.com (сертификат был выдан для www.example.com, а не для example.com)

Какой лучший подход, чтобы https://example.com перенаправлялся на https://www.example.com, и как мне достичь своей цели?

С наилучшими пожеланиями,
Эльми

Я последовал этому совету и добавил строку в мой app.yml:

Хотя мне не мешает, если меня находят по корневому домену или поддомену www, поэтому я не пробовал это с редиректами.

Будьте осторожны с дублирующимся контентом в поисковых системах.

Это область, в которой я не очень силен. :slightly_smiling_face: Какой способ вы бы порекомендовали? У меня сейчас есть A-записи как для домена, так и для поддомена www, которые указывают на мой Droplet от DigitalOcean.

Самый простой способ — использовать для этого www.forcewww.com. (Отказ от ответственности: это мой собственный сервис)

Огромное спасибо за ваш отзыв @JammyDodger. Я попробую, хотя, похоже, это касается немного другой проблемы. Но, возможно, это сработает.

Лучшей практикой является наличие только одной версии вашего сайта. Duplicate Content: Why does it happen and how to fix issues - Moz

Такая перенаправление тривиально реализуется на любом веб-сервере, и достаточно просто найти в Google, как это сделать. Почему здесь всё иначе?

Я вполне уверен, что если вы запросите оба сертификата, перенаправление произойдет так, как вы хотите. Решение от forcewww.com проще.

Потому что это внутри контейнера Docker, и ни одно из решений, работающих внутри хоста, которые вы можете найти в других местах, скорее всего, не подойдет.

Просто короткое обновление, чтобы сообщить, что сработало у меня.

Я пробовал, но это не сработало. Похоже, дополнительный сертификат не был выдан.

Также я попытался решить свою проблему, следуя этой рекомендации, но и это не помогло.

Единственное, что решило мою проблему на данный момент, — это следование инструкциям здесь: http://www.forcewww.com/

Тем не менее, я считаю, что это всё ещё не идеальное решение, так как оно зависит от внешнего сервиса. Конечно, он бесплатен, но вам придётся найти новое решение, когда этот сервис перестанет работать.
Надеюсь, вы не подумаете обо мне неправильно, @michaeld, это действительно удобное и простое решение, которое вы предлагаете, и я очень его ценю.

Было бы здорово, если бы при стандартной установке можно было выбрать вариант только с www или без www, чтобы немного облегчить нам жизнь :slight_smile:

Хотя я не проверял это в последний месяц, я почти уверен, что это работает. Если вы неправильно настроили DNS и запускали это много раз, то вы попали под ограничение по частоте запросов.

Вы имеете в виду «и запросить сертификат для обоих хостнеймов»? Это слишком сложно. Вероятность того, что это просто сломает работу у многих людей, которые не знают, как правильно настроить DNS таким образом, очень, очень высока.

Если вы создадите сертификат как для корневого домена, так и для версии с www, вы покроете оба варианта. :smiley Как вы указали, сертификат не включает ваш корневой домен… отсюда и ошибка.

Ваши перенаправления должны быть следующими:

  • http://example.comhttps://example.com
  • http://www.example.comhttps://www.example.com.
  • Затем перенаправьте https://example.comhttps://www.example.com (ваш предпочтительный домен, указанный выше).

Таким образом, независимо от того, вводит ли пользователь корневой домен или версию с www, они попадут на https://www.example.com без ошибок. Лучшая практика — включить в сертификат как корневой домен, так и версию с www. Просто убедитесь, что ваш обновлённый/новый сертификат именно тот, который обслуживается вашим сервером, а не старый.

Понятно. И теперь, когда вы об этом упомянули, я вспомню — это была вторая причина, по которой я разместил Discourse за «обычным» Nginx. Первая причина заключалась в необходимости выполнить некоторую фильтрацию. Ну, моё решение не является каким-то изысканным или технически сложным, но не так популярно в этом кругу.

Должен сказать, что Docker — не очень дружелюбное к пользователю решение, если такие действительно тривиальные вещи приходится делать с помощью стороннего веб-сервиса. В противном случае Docker, полагаю, очень полезен, если бы он не стал настолько популярным.

Спасибо за совет, @pfaffman. Я попробую снова в эти выходные.

Что касается второй темы, то я понимаю вашу точку зрения, но это может быть настройка для продвинутых пользователей или опциональная опция, поскольку крайне важно, чтобы один и тот же контент был доступен только через один домен.

На самом деле это не так (если только сам Discourse не работает). Но если вы говорите о SEO и Google, то проблема с поддоменами уже давно не является такой серьёзной. Google с этим справляется, поскольку речь идёт об одном домене: один — это псевдо-полное доменное имя (FQDN), а другой с www — настоящее.