autorizzazione nginx negata ai file di certificato per la configurazione SSL

Sto installando un proxy ssl nginx sul mio server Fedora.

Ho creato una coppia di certificati e chiavi in / etc / nginx. Sembrano così:

ls -l /etc/nginx/
total 84
...
-rw-r--r--. 1 root root 1346 Sep 20 12:11 demo.crt
-rw-r--r--. 1 root root 1679 Sep 20 12:11 demo.key

...

Come root, sto cercando di avviare il servizio nginx:

systemctl start nginx.service

Ottengo il seguente errore:

nginx[30854]: nginx: [emerg]
SSL_CTX_use_certificate_chain_file("/etc/nginx/demo.crt") failed (SSL: error:0200100D:system     library:fopen:Permission denied...e:system lib)
nginx[30854]: nginx: configuration file /etc/nginx/nginx.conf test failed

C'è qualcosa di sbagliato con le autorizzazioni su questi file?

nginx ssl ssl-certificate

— numb3rs1x
fonte

Indica la catena di certificati ... non è il problema con l'autorità di certificazione di quella chiave demo.crt? O è un certificato autofirmato? A proposito, non credo che il file chiave dovrebbe essere leggibile dal mondo. Nginx dovrebbe aprirlo come root e quindi rilasciare i privilegi a qualsiasi utente venga eseguito.

— Aleš Krajník,

È autofirmato, sì. Cambierò la proprietà, grazie.

— numb3rs1x

Si presume che il problema riguardi i certificati, ma il messaggio di errore si applica al file di configurazione per Nginx.

— bbaassssiiee,

Risposte:

Probabilmente hai SELinux in modalità esecutiva (il valore predefinito per Fedora):

sestatus -v

In questo caso, controlla i log di controllo, dovresti trovare l'errore di accesso:

ausearch -m avc -ts today | audit2allow

Probabilmente hai anche spostato il file invece di copiarlo, quindi il contesto di sicurezza del file potrebbe essere sbagliato.

ls -lrtZ /etc/nginx/demo.*

e correggerlo se necessario:

restorecon -v -R /etc/nginx

— Dawud
fonte

Grazie mille. Ho seguito le tue istruzioni e non ricevo più l'errore. Mi è capitato di spostare questi file dalla directory in cui li ho creati. Posso crearli nella stessa directory la prossima volta. A parte questo, come posso evitare che ciò accada in futuro?

— numb3rs1x

Per questo caso d'uso specifico, utilizzare cpanziché mve imparare a utilizzare il auditsistema per cercare i rifiuti AVC.

— Dawud,

Il ausearch | comando audit2allow. Ciò ha aggiunto alcune autorizzazioni a selinux o è stato solo per confermare che selinux era il problema?

— numb3rs1x

Era solo per confermare. Leggi le rispettive pagine di manuale per i dettagli.

— Dawud,

Wow grazie! È bello avere una risposta che non sia solo "disabilitare SELinux".

— BCran,

Immagino sia SELinux a negare il permesso. Controlla il loro contesto SELinux. Il loro dovrebbe essere httpd_config_t. Altrimenti, scappa

restorecon /etc/nginx/demo.*

chcon httpd_config_t /etc/nginx/demo.*

come radice.

Puoi controllare i log in / var / log / audit / per vedere se è SELinux che nega l'autorizzazione. Puoi anche correre

setenforce 0

per impostare SELinux in modalità permissiva . In questo modo, SELinux genera ancora messaggi AVC (in / var / log / audit /) ma consente l'accesso.

— jdh8
fonte