Как заставить 'www' работать с Discourse

Поддержка
21

Нет, дополнительная установка не требуется.

Также единственный блок, который мне нужно было добавить, это:

  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d mywebsite.org --keylength"

(перенаправление с HTTP на HTTPS, похоже, работает корректно без двух других блоков replace, тех, что с nginx)

22

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

В мой файл containers/app.yml я добавил гораздо больше настроек, чем вы, и почти всё работает корректно.

Мой Discourse размещён на поддомене www, и моей целью было перенаправление запросов http и https с корневой зоны домена на поддомен www. Это теперь работает, но если я перехожу по адресу https://mydomain.com, происходит перенаправление, однако в консоли Chrome появляется следующее предупреждение:

Redirecting navigation example.com -> www.example.com because the server presented a certificate valid for www.example.com but not for example.com. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling

Вот мои дополнения к app.yml:

 after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com -d www.example.com --keylength"
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301 https.+/
        to: |
          return 301 https://$host$request_uri;
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /gzip on;[^\}]+\}/m
        to: |
          gzip on;
          add_header Strict-Transport-Security 'max-age=31536000'; # remember the certificate for a year and automatically connect to HTTPS for this domain
  after_web_config:
    - replace:
        filename: /etc/nginx/nginx.conf
        from: /sendfile.+on;/
        to: |
          server_names_hash_bucket_size 64;
          sendfile on;
    - file:
      path: /etc/nginx/conf.d/discourse_redirect_1.conf
      contents: |
        server {
          listen 80;
          listen 443 ssl;
          server_name example.com;
          return 301 https://www.example.com$request_uri;
        }

Выглядит ли это правильно? Если да, то есть ли решение проблемы несоответствия имени сертификата?

РЕДАКТИРОВАНИЕ: У меня есть две записи A: одна для поддомена www, а другая с использованием @ для перехвата всех запросов к корневой зоне домена. Обе указывают на IP-адрес моего сервера Digital Ocean. Предполагаю, что это тоже верно?

Спасибо.

23

Бесплатно в реализации, даже если Cloudflare не является вашим регистратором. Работает с HTTPS, без дополнительных сложностей в вашей установке Discourse.

24

Спасибо, я сейчас не использую Cloudflare, поэтому раньше с этим не сталкивался. Я пошёл другим путём и следовал инструкциям выше, в основном удалось решить мою проблему. Вы опубликовали сообщение как раз в тот момент, когда я отправил свой ответ выше.

25

Пожалуйста, проверьте этот веб-сайт: есть ли там все необходимые вам редиректы? Это реализовано всего одним блоком replace (см. выше) и следующей настройкой DNS (я скрыл только TXT-записи с email):

image
image1421×550 14.9 KB

В консоли у меня нет никаких предупреждений.

26

Да, просто будьте готовы к тому, что это сломается, когда изменится конфигурация Let’s Encrypt.

Когда Let’s Encrypt обновили для поддержки эллиптических кривых, описанный выше подход в течение нескольких недель не работал.

28

Единственное отличие в том, что у меня нет записи CAA в моём DNS. Я добавлю её, используя то же значение, которое вы использовали.

Предполагаю, что хостнейм вашего Discourse — www.example.com. Уверены ли вы, что при доступе к https://example.com у вас не появляется предупреждение?

В Chrome на Android это предупреждение ещё серьёзнее: он полностью блокирует сайт и не выполняет перенаправление.

29

Теперь я вас не понимаю :slight_smile: На что мне нужно обращать внимание / быть готовым исправить?

30

Верно.

Да, я уверен, предупреждений в консоли нет.

31

Я думаю, я нашел проблему. У меня было так:

after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com -d www.example.com --keylength"

А должно было быть так:

after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com --keylength"

Обратите внимание на последнюю строку: у меня были указаны и example.com, и www.example.com.

Также я заменил return 301 https://$host$request_uri; на return 301 $scheme://$host$request_uri;. После пересборки всё, кажется, работает.

Теперь меня беспокоит лишь то, что упомянул @Stephen: это может сломаться, если конфигурация letsencrypt изменится.

32

Изменение, внесённое 9 сентября прошлого года, нарушило подход, которому вы следовали, и поскольку реализация выходила за рамки стандартной установки, решение было опубликовано только 31 октября. Если вы посмотрите на тему, которой вы следовали, и историю правок в вики, это чётко задокументировано.

Поскольку вы не занимаетесь чем-то, что требует глубокого погружения в дополнительную конфигурацию, я бы не рекомендовал этого делать. С другой стороны, когда Let’s Encrypt действительно внесёт изменения, и вы затронете их, мы сможем направить вас обратно к этой теме.