Uruchomienie Nginx kończy się niepowodzeniem ssl nie ma takiego pliku ani katalogu

Oto błąd, który otrzymuję:

Ponowne ładowanie konfiguracji nginx: nginx: [emerg] SSL_CTX_use_certificate_chain_file ("/ path / to / cert.pem") nie powiodło się (SSL: błąd: 02001002: biblioteka systemowa: fopen: brak takiego pliku lub błędu katalogu: 20074002: procedury BIO: FILE_CTRL: system błąd lib: 140DC002: Procedury SSL: plik_certyfikatu_ SSL_CTX: łańcuch_certyfikatu: lib systemowy nginx: plik konfiguracyjny /etc/nginx/nginx.conf nie powiódł się

Jestem w 100% pewien, że plik znajduje się w tej lokalizacji, ale Nginx wydaje się myśleć, że go nie ma. Połączyłem domain.crti intermediate.crtręcznie w tej kolejności. Drapałem się nad tym przez cały dzień. Mam nadzieję, że ktoś widział ten błąd i ma rozwiązanie (i na marginesie to nie błąd w wklejaniu, że lokalizacja pliku jest wyświetlana tylko raz, a nie ponownie po „braku takiego pliku lub katalogu”).

Czy jesteś pewien, że użytkownik Nginx ma dostęp do katalogu?

Sprawdź także uprawnienia do .pempliku, jeśli Nginx nie może uzyskać do niego dostępu, może pokazać jako 'no such file or directory'.

Jeśli uprawnienia są prawidłowe, możesz ponownie sprawdzić rzeczywistą ścieżkę. Jak to wkleiłeś (wiem, że usunąłeś katalog), nie ma początku, /który mógłby być problemem.

EDYTOWAĆ

Spróbuj przenieść konfigurację SSL do następującej struktury (a także zmień ją nginx.confna odzwierciedlającą):

sudo mkdir /etc/nginx/ssl
sudo chown -R root:root /etc/nginx/ssl
sudo chmod -R 600 /etc/nginx/ssl

Nginx może zawieść na twoim, .pemponieważ uprawnienia są zbyt otwarte (potrzebujesz źródła, aby sprawdzić, czy Nginx to robi), ale powyższa konfiguracja powinna działać poprawnie.

Pozostawię swoją odpowiedź na mój problem, na wypadek, gdyby ktoś natknął się na ten temat.

Mam nginx uruchomiony w kontenerze dokera i mam ten sam błąd podczas próby uzyskania dostępu do pliku klucza prywatnego. Po kilku godzinach drapania się w głowę doszedłem do wniosku, że nginx mojego dokera nie ma woluminu montowania zawierającego moje dane.

Jedyną opcją dodania woluminu montowania jest usunięcie i ponowne utworzenie kontenera z -vopcją: https://docs.docker.com/engine/tutorials/dockervolumes/

docker run -d -P --name docker-nginx -v /etc/ssl/certs:/etc/ssl/certs nginx

Czasami trywialne rzeczy są trudne do zobaczenia. Mam nadzieję, że to pomoże.

Możliwy scenariusz:

czasami może się zdarzyć, że podczas konfigurowania plików SSL (klucz prywatny i certyfikat) dla konfigurowanego hosta wirtualnego zapomniano podać bezwzględną ścieżkę, w której znajdują się te pliki.

Na przykład, jeśli postępujesz zgodnie z tym oficjalnym dokumentem od Nginx: http://nginx.org/en/docs/http/configuring_https_servers.html

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     tdmssl.crt;
    ssl_certificate_key tdmssl.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

Załóżmy, że przechowujesz pliki SSL w „ /etc/nginx/conf.d ”:

root@ilg40:/etc/nginx/conf.d# pwd
/etc/nginx/conf.d
root@ilg40:/etc/nginx/conf.d# ll
total 16
drwxr-xr-x 2 root root 4096 Jan 24 17:39 ./
drwxr-xr-x 5 root root 4096 Jan 24 21:15 ../
-rw-r--r-- 1 root root 1359 Jan 24 17:39 tdmssl.crt
-rw-r--r-- 1 root root 1675 Jan 24 17:39 tdmssl.key

Co się dzieje?

Domyślnie, jeśli nie zostanie podana ścieżka bezwzględna dla zwykłego pliku, który jest używany przez Nginx, Nginx będzie szukał plików w „/ etc / nginx”

Z /var/log/nginx/error.log

2017/01/24 21:05:10 [emerg] 13113#0: 
BIO_new_file("/etc/nginx/tdmssl.crt") 
failed(SSL:error:02001002:system library:fopen:
No such file or directory:fopen('/etc/nginx/tdmssl.crt','r') 
error:2006D080:BIO routines:BIO_new_file:no such file)

Co musi być zrobione ?

Aby określić bezwzględną ścieżkę dodatkowych plików, które są używane przez konfigurację Virtualhost.

Lubię to:

root@ilg40:/etc/nginx/conf.d# cd
root@ilg40:~# cat /etc/nginx/sites-available/tdm 
server {

    listen          443 ssl;
    server_name         tjsdatamanager.redtjs.com;
    ssl_certificate     /etc/nginx/conf.d/tdmssl.crt;
    ssl_certificate_key /etc/nginx/conf.d/tdmssl.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        include proxy_params;
        proxy_pass http://unix:/etc/tdm/flask/wsgi.sock;
    }

}

Miałem ten sam problem. Musiałem zmienić pliki / etc / nginx / sites-enabled / default & default.save, które zostały automatycznie dodane do mojej strony bez nazwy .com po jej zakończeniu w trakcie procesu instalacji, co było problemem w mojej instancji . Krótko mówiąc, te dwie linie musiały zostać zmienione w moim / etc / nginx / sites-enabled / default. Pamiętaj, że ten plik jest wyświetlany z ikoną skrótu w moim systemie plików, ale byłem w stanie kliknąć go prawym przyciskiem myszy i edytować za pomocą opcji „Edytuj / Edytor wewnętrzny”.

HTTPS - żądania proxy do lokalnej aplikacji Node.js ap # HTTPS - żądania proxy do lokalnej aplikacji Node.js: serwer {nasłuchuj 443; nazwa_serwera switchmagic.com;

    ssl on;
    # Use certificate and key provided by Let's Encrypt:
    ssl_certificate /etc/letsencrypt/live/switchmagic.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/switchmagic.com/privkey.pem;

Kiedy przejrzałem pliki i dodałem .com, czyli konwencję nazewnictwa, której użyłem, aby dodać plik, do odniesień switchmagic w katalogach plików, które generowały błędy, wszystko było dobrze! Znalazłem wielu deweloperów zadających to samo pytanie, więc chciałem tam rzucić rozwiązanie, ponieważ odpowiedzi, które znalazłem, dotyczyły głównie uprawnień root, ale uprawnienia root nie były moim problemem. Rock on Devs.