Manière supportée d'ajouter "IncludeSubdomain" aux en-têtes STS

Bonjour à tous,

pour nos instances Discourse auto-hébergées actuelles, nous devons ajouter « IncludeSubDomains » à nos en-têtes STS en raison d’une attente de nos scanners internes.

Auparavant, j’y parvenais en utilisant des commandes sed dans app.yml dans les commandes personnalisées après la construction pour mettre à jour /etc/nginx/conf.d/discourse.conf afin d’inclure 'add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always;

ainsi que :

 - replace:
      filename: "/etc/nginx/conf.d/outlets/discourse/20-https.conf"
      from: /add_header Strict-Transport-Security.+/
      to: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
      global: true

  - replace:
      filename: "/etc/nginx/conf.d/outlets/server/20-https.conf"
      from: /add_header Strict-Transport-Security.+/
      to: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
      global: true

Cela fonctionnait auparavant. Cependant, cela a cessé de fonctionner. J’ai lu que la création d’un nouveau fichier de sortie devrait me permettre d’ajouter ceci en utilisant :

hooks:
  after_code:
    - file:
        path: /etc/nginx/conf.d/outlets/server/90-hsts.conf
        chmod: 444
        contents: |
          add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Cependant, cela entraîne la présence de deux en-têtes STS (un provenant du modèle SSL et un provenant de mon nouveau modèle). Existe-t-il une meilleure façon de procéder afin de ne pas me retrouver avec deux en-têtes STS ? Je pensais que nginx respecterait le dernier en-tête ajouté et ignorerait l’en-tête du modèle SSL qui ne contient que max-age=31536000; , est-ce donc un bogue ? Merci pour tout conseil que vous pourrez me donner.

Utiliser set_header au lieu de add_header résout-il le problème ?

1 « J'aime »

Je vais essayer et je vous ferai un retour :slight_smile:

Si j’utilise set_header, j’obtiens une erreur SSL lors de la reconstruction, le certificat n’étant pas reconnu et un message de « connexion refusée » lors de la tentative de chargement de la page du forum.

Quelques informations supplémentaires, nous utilisons notre propre certificat SSL.

Ces deux erreurs s’excluent mutuellement…

Désolé, nginx n’a pas set_header - je me suis trompé et cela provient d’un autre outil.

L’option la plus simple est probablement de modifier templates/web.ssl.template.yml avec les nouvelles valeurs souhaitées.

1 « J'aime »

Je ferais cela en premier car c’est le plus facile. Une fois que vous aurez trouvé, la deuxième chose la plus simple est de copier ce fichier ailleurs afin de ne pas avoir de problèmes de conflit avec git. La meilleure solution serait de combiner votre stratégie actuelle avec une autre ligne pour supprimer l’autre paramètre conflictuel.

1 « J'aime »

Merci pour votre aide à tous les deux !

1 « J'aime »