2016-07-14 8 views
12

Ich hatte gearbeitet Lassen Sie uns Zertifikate vor einigen Monaten verschlüsseln (mit dem alten Letsencrypt-Client). Der Server, den ich verwende, ist nginx.Certbot erstellt keinen acme-challenge-Ordner

Certbot schafft die .nun bekannten Ordner, nicht aber die Acme-challenge Ordner

Jetzt habe ich versucht, über ~/certbot-auto certonly --webroot -w /var/www/webroot -d domain.com -d www.domain.com -d git.domain.com

neue Zertifikate erstellen Aber ich immer Fehler wie diese:

IMPORTANT NOTES: 
    - The following errors were reported by the server: 

    Domain: git.domain.com 
    Type: unauthorized 
    Detail: Invalid response from 
    http://git.domain.com/.well-known/acme-challenge/ZLsZwCsBU5LQn6mnzDBaD6MHHlhV3FP7ozenxaw4fow: 
    "<.!DOCTYPE html> 
    <.html lang='en'> 
    <.head prefix='og: http://ogp.me/ns#'> 
    <.meta charset='utf-8'> 
    <.meta content='IE=edge' http-equiv" 

    Domain: www.domain.com 
    Type: unauthorized 
    Detail: Invalid response from 
    http://www.domain.com/.well-known/acme-challenge/7vHwDXstyiY0wgECcR5zuS2jE57m8I3utszEkwj_mWw: 
    "<.html> 
    <.head><.title>404 Not Found</title></head> 
    <.body bgcolor="white"> 
    <.center><.h1>404 Not Found</h1></center> 

(Natürlich sind die Punkte in den HTML-Tags nicht wirklich da)

Ich habe nach einer Lösung gesucht, aber nicht gefunden eins noch. Weiß jemand, warum certbot die Ordner nicht erstellt?

Vielen Dank im Voraus!

Antwort

7

Das Problem war die Nginx-Konfiguration. Ich ersetzte meine lange Konfigurationsdateien mit der einfachsten Konfiguration möglich:

server { 
    listen 80; 
    server_name domain.com www.domain.com git.domain.com; 
    root /var/www/domain/; 
} 

Dann neue Zertifikate auszustellen ich konnte.

Das Problem mit meinen langen Konfigurationsdateien war (soweit ich das beurteilen kann), dass ich die folgenden Zeilen hatte:

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

Aber sie sollten sein: die Erneuerungsarbeiten

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

Jetzt , auch.

+6

Es ist erwähnenswert, dass Certbot das '.well-known'-Verzeichnis löscht, nachdem es versucht hat, das Problem zu beheben. Wenn Sie also davon ausgehen, dass das Problem mit der Dateigenerierung anstelle der Dateibereitstellung besteht, können Sie sicher sein, dass dies nicht der Fall ist. Der Fehler, den Sie erhalten, wenn es Berechtigungsfehler gibt, ist unterschiedlich. – DfKimera

+0

Beachten Sie, dass in diesem Fall alle Subdomänen dasselbe Stammverzeichnis verwenden. Einen Server pro Root zu erstellen ist eine Lösung (vielleicht nicht die beste, aber es funktioniert), wenn mehrere Roots verwendet werden. – aluriak

+0

Diese Lösung hat bei mir nicht funktioniert. Ich habe "location /.well-known {.. allow all;}. Strace zeigt an, dass certbot das acme-challenge-Verzeichnis löscht, wenn es manuell erstellt wird, bevor es certbot startet. Dann kann die Challenge-Datei nicht geöffnet werden. – rhoerbe

3

Ich hatte ein ähnliches Problem. Mein Problem war, dass ich diese Regel hatte: „“

location ~ /\. { 
    access_log off; 
    log_not_found off; 
    deny all; 
} 

diese Zeilen in dem jeden Zugang zu einem beliebigen Verzeichnis Cancelling mit Start einer (Punkt)

+2

Ich hatte dieses Problem too (Standard für Wordpress auf Nginx), aber es ist eine wertvolle Regel, also platziere sie einfach nach der 'location ~/.well-known'-Regel –

0

Ich hatte ein albernes Problem - beim Ausführen des certbot-Befehls hatte ich ein webroot-Attribut, das auf das Stammverzeichnis meines Repositorys und nicht auf das öffentliche Verzeichnis zeigte.

Verwandte Themen