# Rendre « www » fonctionnel avec Discourse

**URL:** https://meta.discourse.org/t/making-www-work-with-discourse/150785
**Category:** Support
**Created:** [Mai 8, 2020, 4:23 UTC](https://meta.discourse.org/t/making-www-work-with-discourse/150785 "2020-05-08T04:23:38Z")
**Posts on this page:** 1
**Showing post:** 22

<div class="post-metadata">

### Author: ![Milo](https://avatars.discourse-cdn.com/v4/letter/m/85e7bf/32.png) [@Milo](https://meta.discourse.org/u/Milo)
#### Post date: [Mai 15, 2020, 1:11 UTC](https://meta.discourse.org/t/making-www-work-with-discourse/150785/22 "2020-05-15T13:11:00Z")

</div>

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](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.

---

_[View the full topic](https://meta.discourse.org/t/making-www-work-with-discourse/150785)._