Permissão nginx negada para arquivos de certificado para configuração SSL

Estou instalando um proxy nginx ssl no meu servidor Fedora.

Eu criei um par de certificados e chaves em / etc / nginx. Eles se parecem com isso:

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

...

Como root, estou tentando iniciar o serviço nginx:

systemctl start nginx.service

Estou tendo o erro a seguir:

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

Há algo de errado com as permissões nesses arquivos?

nginx ssl ssl-certificate

— numb3rs1x
fonte

Ele menciona a cadeia de certificados ... não é o problema com a autoridade de certificação dessa chave demo.crt? Ou é um certificado autoassinado? A propósito, acho que o arquivo-chave não deve ser lido pelo mundo. O Nginx deve abri-lo como root e, em seguida, largar privilégios para qualquer usuário que execute.

— Aleš Krajník 20/09/2013

É autoassinado, sim. Vou mudar de propriedade, obrigado.

— Numb3rs1x 20/09/2013

Você assume que o problema está nos certificados, mas a mensagem de erro se aplica ao arquivo de configuração do Nginx.

— bbaassssiiee

Respostas:

Você provavelmente tem o SELinux no modo de imposição (o padrão para o Fedora):

sestatus -v

Se for esse o caso, verifique os logs de auditoria, você deve encontrar o erro de acesso:

ausearch -m avc -ts today | audit2allow

Você provavelmente também moveu o arquivado em vez de copiá-lo, portanto o contexto de segurança do arquivo pode estar errado.

ls -lrtZ /etc/nginx/demo.*

e corrija-o se necessário:

restorecon -v -R /etc/nginx

— dawud
fonte

Muito obrigado. Segui suas instruções e não estou mais recebendo o erro. Por acaso, movi esses arquivos do diretório em que os criei. Eu posso criá-los no mesmo diretório da próxima vez. Fora isso, como impedir que isso aconteça no futuro?

— Numb3rs1x 20/09/2013

Para este caso de uso específico, use em cpvez de mve aprenda a usar o auditsistema para procurar negações do AVC.

— dawud 20/09/2013

A ausearch | comando audit2allow. Isso adicionou algumas permissões ao selinux ou foi apenas para confirmar que o selinux era o problema?

— Numb3rs1x 20/09/2013

Foi apenas para confirmar. Leia as respectivas páginas de manual para obter detalhes.

— dawud 20/09/2013

Uau, obrigada! É bom ter uma resposta que não seja apenas 'desativar o SELinux'.

— BCRAN

Eu acho que é o SELinux que nega permissão. Verifique o contexto do SELinux. Eles devem ser httpd_config_t. Caso contrário, execute

restorecon /etc/nginx/demo.*

chcon httpd_config_t /etc/nginx/demo.*

como raiz.

Você pode verificar os logs em / var / log / audit / para ver se é o SELinux que nega permissão. Você também pode executar

setenforce 0

para configurar o SELinux no modo permissivo . Dessa forma, o SELinux ainda gera mensagens AVC (em / var / log / audit /), mas permite o acesso.

— jdh8
fonte