Rendre « www » fonctionnel avec Discourse

Soutien
22

J’ai enfin trouvé le temps de parcourir les guides « Configuration de Let’s Encrypt avec plusieurs domaines » et « Redirection d’un ou plusieurs domaines vers votre instance Discourse ».

J’ai ajouté beaucoup plus de choses à mon fichier containers/app.yml que vous, et presque tout fonctionne correctement.

Mon Discourse est hébergé sur le sous-domaine www, et mon objectif était de rediriger les requêtes HTTP et HTTPS depuis le domaine de premier niveau (apex) vers le sous-domaine www. Cela fonctionne désormais, mais lorsque je vais sur https://mydomain.com, la redirection s’effectue, mais Chrome affiche l’avertissement suivant dans la console :

Redirection de navigation example.com -> www.example.com car le serveur a présenté un certificat valide pour www.example.com mais pas pour example.com. Pour désactiver ce type de redirection, lancez Chrome avec le drapeau suivant : --disable-features=SSLCommonNameMismatchHandling

Voici mes ajouts au fichier 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'; # mémoriser le certificat pendant un an et se connecter automatiquement en HTTPS pour ce domaine
  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;
        }

Cela semble-t-il correct ? Si oui, existe-t-il une solution au problème de mismatch de nom de certificat ?

MODIFICATION : J’ai deux enregistrements A, l’un pour le sous-domaine www et l’autre utilisant @ pour capturer toutes les requêtes vers le domaine de premier niveau. Tous deux pointent vers l’adresse IP de mon droplet Digital Ocean. Je suppose que cela est également correct ?

Merci.

1 « J'aime »