Nginx désactive .htaccess et les fichiers cachés mais autorise les répertoires .well connus

16

J'ai un serveur Nginx et j'ai désactivé les fichiers cachés dans le nginx_vhost.conf

## Disable .htaccess and other hidden files
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }

Mais LetsEncrypt a besoin d'accéder au .well-knownrépertoire.

Comment autoriser le .well-knownrépertoire et refuser les autres fichiers cachés?

nginx virtualhost lets-encrypt

— Janghou
source

Remarque: nginx n'utilise pas ou n'a pas de .htaccessfichiers. Il a des fichiers de configuration mais ils ne sont pas appelés .htaccesset ne fonctionnent pas de la même manière.

— Rob

17

Les autres solutions ne m'ont pas aidé.

Ma solution consiste à inclure une expression rationnelle négative pour .well-known. Votre bloc de code devrait alors ressembler à ceci:

## Disable .htaccess and other hidden files
location ~ /\.(?!well-known).* {
    deny all;
    access_log off;
    log_not_found off;
}

Il bloquera tous les fichiers de points sauf ceux commençant par .well-known

PS: j'ajouterais également return 404;au bloc.

— therealmarv
source

1

Est-ce location ~* /\.(?!well-known\/) {que vu sur github.com/h5bp/server-configs-nginx/blob/master/h5bp/location/… identique à cela location ~ /\.(?!well-known).* { ?

— Pro Backup

3

non ce n'est pas exactement pareil. /\.(?!well-known\/)n'est pas aussi expressif que mon expression régulière (parce que je bloque tous les fichiers de points, sauf bien connus par définition). Le mieux serait peut-être une combinaison comme celle location ~ /\.(?!well-known\/).*qui débloque uniquement le répertoire bien connu au lieu d'une théorie .well-known-blabla. Mais je pense qu'il n'y a pas de réel danger à ne pas bloquer un fichier théorique .well-known-blabla.

— therealmarv

pourquoi désactiver htaccess puisque de toute façon Nginx ne le gère pas?

— Webwoman

3

Oui, vous avez raison @webwoman mais parfois il y a des environnements mixtes. Tout fichier dot ne devrait pas être servi à mon avis (sécurité ou exposition indésirable de l'histoire comme avec .git) sauf si vraiment nécessaire.

— therealmarv

16

Nginx applique les emplacements avec des expressions régulières dans l'ordre de leur apparition dans le fichier de configuration.

Par conséquent, l'ajout d'une entrée comme celle-ci juste avant votre position actuelle vous aidera.

location ~ /\.well-known { 
    allow all;
}

— Weirdei
source

Merci, c'est exactement ce dont j'avais besoin! Placé ceci avant une règle refusant l'accès à tous les fichiers dot. La seule chose que j'ai changé était d'échapper au point, par exemple location ~ /\.well-known {. Quoi qu'il en soit, cela devrait être la réponse acceptée.

— aexl

8

J'ai fourni un tutoriel complet étape par étape sur la façon d'utiliser Let's Encrypt avec NGINX sur mon site Web.

Les éléments clés sont:

Le client officiel n'est que correct et est vraiment pauvre sur Amazon Linux. Je recommande un autre client, ACME .
Utilisez cet emplacement pour la méthode webroot, avec mon client recommandé. Notez que les demandes sont servies via http, pas https.

Vous n'avez pas du tout besoin d'écouteurs dans votre bloc https, tout se fait sur https. C'est seulement pour prouver que vous contrôlez le domaine, il ne sert rien de privé ou de secret.

# Answer let's encrypt requests, but forward everything else to https
server {
  listen       80;
  server_name  example.com www.example.com
  access_log  /var/log/nginx/access.log main;

  # Let's Encrypt certificates with Acmetool
  location /.well-known/acme-challenge/ {
    alias /var/www/.well-known/acme-challenge/;
  }

  location / {
    return       301 https://www.example.com$request_uri;
  }
}

Guide étape par étape complet lié ci-dessus.

— Tim
source

3

Ajoutez ceci (avant ou après):

location ^~ /.well-known/ {
        log_not_found off;
     }

Vous pouvez également l'ajouter en bas, car le ^~modificateur de correspondance a priorité sur les expressions régulières. Voir la documentation .

— Janghou
source

0

Si vous avez beaucoup de fichiers de configuration et qu'ils contiennent déjà un refus sur .htaccess comme

location ~ /\.ht { deny all; }

puis au lieu d'ignorer tous les fichiers de points , vous pouvez simplement ajouter un deuxième ignorer pour .git avec

sed -i '/location ~ \/\\.ht { deny all; }/a \  location ~ \/\\.git { deny all; }' /etc/nginx/*

— rubo77
source