Far funzionare 'www' con Discourse

Supporto
22

Alla fine ho trovato il tempo per lavorare sulle guide “Configurazione di Let’s Encrypt con più domini” e “Reindirizzamento di uno o più domini alla tua istanza Discourse”.

Ho aggiunto molto di più al mio file containers/app.yml rispetto a quanto hai fatto tu e quasi tutto funziona correttamente.

Il mio Discourse è ospitato sul sottodominio www e il mio obiettivo era reindirizzare le richieste HTTP e HTTPS dal dominio apice al sottodominio www. Ora funziona, ma se vado su https://mydomain.com, anche se avviene il reindirizzamento, Chrome mostra il seguente avviso nella console:

Reindirizzamento della navigazione example.com -> www.example.com perché il server ha presentato un certificato valido per www.example.com ma non per example.com. Per disabilitare tali reindirizzamenti, avvia Chrome con il flag seguente: --disable-features=SSLCommonNameMismatchHandling

Ecco le mie aggiunte al file 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'; # ricorda il certificato per un anno e connettiti automaticamente a HTTPS per questo dominio
  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;
        }

Sembra tutto corretto? In tal caso, esiste una soluzione al problema di disallineamento del nome del certificato?

EDIT: Ho due record A, uno per il sottodominio www e un altro che utilizza @ per intercettare tutte le richieste al dominio apice. Entrambi puntano all’IP del mio droplet Digital Ocean. Immagino che anche questo sia corretto?

Grazie.