Fazendo o 'www' funcionar com o Discourse

Suporte
22

Então, finalmente consegui tempo para trabalhar nos guias ‘Configurando o Let’s Encrypt com Múltiplos Domínios’ e ‘Redirecionar domínio único/múltiplo(s) para sua instância Discourse’.

Adicionei muito mais ao meu arquivo containers/app.yml do que você, e quase tudo funciona corretamente.

Meu Discourse está hospedado no subdomínio www, e meu objetivo era redirecionar as solicitações http e https do domínio principal (apex) para o subdomínio www. Isso agora funciona, mas quando acesso https://mydomain.com, ele redireciona, porém o Chrome exibe o seguinte aviso no console:

Redirecionando navegação example.com -> www.example.com porque o servidor apresentou um certificado válido para www.example.com, mas não para example.com. Para desativar esse tipo de redirecionamento, inicie o Chrome com a seguinte flag: --disable-features=SSLCommonNameMismatchHandling

Aqui estão minhas adições ao 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'; # lembre o certificado por um ano e conecte automaticamente via HTTPS para este domínio
  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;
        }

Isso parece correto? Se sim, existe uma solução para o problema de incompatibilidade do nome do certificado?

EDIT: Tenho dois registros A, um para o subdomínio www e outro usando @ para capturar todas as solicitações ao domínio principal. Ambos apontam para o IP do meu droplet da Digital Ocean. Suponho que isso também esteja correto?

Obrigado.