2016-07-14 328 views
12

Ho funzionato Facciamo crittografare i certificati alcuni mesi fa (con il vecchio client di let-script). Il server che sto usando è nginx.Certbot non sta creando la cartella acme-challenge

Certbot sta creando la cartella beh noti, ma non la cartella acme-sfida

Ora ho cercato di creare nuovi certificati via ~/certbot-auto certonly --webroot -w /var/www/webroot -d domain.com -d www.domain.com -d git.domain.com

ma ottengo sempre gli errori come questo:

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> 

(Ovviamente i punti all'interno dei tag HTML non sono proprio lì)

Ho cercato una soluzione, ma non ho trovato uno ancora. Qualcuno sa perché certbot non sta creando le cartelle?

Grazie in anticipo!

risposta

7

Il problema era la configurazione di nginx. Ho sostituito le mie lunghe file di configurazione con la configurazione più semplice possibile:

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

Poi sono stato in grado di emettere nuovi certificati.

Il problema con i miei file lunghi di configurazione è stato (per quanto posso dire) che ho avuto le queste righe:

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

ma dovrebbero essere:

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

Ora le opere di rinnovo , pure.

+6

Vale la pena ricordare che Certbot cancellerà la directory '.well-known' dopo aver tentato di eseguire il rilascio. Quindi, se ci stai pensando che il problema sia con la generazione di file invece di servire i file, ti assicuro che non lo è. L'errore che si verifica quando sono presenti errori di autorizzazione è diverso. – DfKimera

+0

Si noti che in questo caso, tutti i sottodomini utilizzano la stessa directory root. Creare un server per root è una soluzione (forse non la migliore, ma funziona) se si utilizzano più radici. – aluriak

+0

Queste soluzioni non hanno funzionato per me. Ho "location /.well-known {.. allow all;}. Strace mostra che certbot cancella la directory acme-challenge quando viene creata manualmente prima di avviare certbot. Quindi non riesce ad aprire il file challenge. – rhoerbe

3

Ho avuto un problema simile. Il mio problema era, che ho avuto questa regola: ""

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

queste righe in cui l'annullamento ogni accesso a qualsiasi directory di partenza con un (punto)

+2

Ho avuto questo problema troppo (predefinito per Wordpress su Nginx) ma è una regola valida, quindi basta posizionarlo dopo la regola 'location ~/.well-known' –

0

Ho avuto un problema stupido - durante l'esecuzione del comando certbot ho avuto attributo webroot che punta alla directory principale del mio repository e non quella pubblica.