Назад | Перейти на главную страницу

Ошибка запуска Nginx по ssl нет такого файла или каталога

Вот ошибка, которую я получаю:

Повторная загрузка конфигурации nginx: nginx: [Emerg] SSL_CTX_use_certificate_chain_file ("/ путь / к / cert.pem") не удалось (SSL: ошибка: 02001002: системная библиотека: fopen: Нет такого файла или ошибки каталога: 20074002: подпрограммы BIO: FILE_CTRL: система ошибка библиотеки: 140DC002: подпрограммы SSL: SSL_CTX_use_certificate_chain_file: system lib) nginx: файл конфигурации /etc/nginx/nginx.conf не прошел тест

Я на 100% уверен, что файл находится в этом месте, но Nginx, похоже, думает, что его там нет. Я объединил domain.crt и intermediate.crt вручную в таком порядке. Я весь день ломал голову над этим. Я надеюсь, что кто-то видел эту ошибку и нашел решение. (И примечание стороны, это не ошибка при вставке, что расположение файла отображается только один раз, а не снова после «нет такого файла или каталога»).

Вы уверены, что у пользователя Nginx есть доступ к каталогу?

Также проверьте разрешения .pem файл, если Nginx не может получить к нему доступ, он может отображаться как 'no such file or directory'.

Если разрешения правильные, вы можете еще раз проверить фактический путь. Как вы его вставили (я знаю, что вы удалили директорию), начала нет / что могло быть проблемой.

РЕДАКТИРОВАТЬ

Попробуйте переместить настройку SSL в следующую структуру (а также изменить nginx.conf отражать):

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

Nginx может дать сбой на вашем .pem потому что разрешения слишком открыты (нужен источник, чтобы убедиться, что Nginx делает это), но вышеуказанная настройка должна работать нормально.

Я оставлю свой ответ по своей проблеме, если кто-нибудь столкнется с этой темой.

У меня nginx работает внутри контейнера докеров, и у меня такая же ошибка при попытке доступа к файлу закрытого ключа. Почесав голову в течение нескольких часов, я пришел к выводу, что у моего докера nginx нет тома монтирования, содержащего мои данные.

Единственный вариант добавить монтируемый том - удалить и воссоздать контейнер с -v вариант: https://docs.docker.com/engine/tutorials/dockervolumes/

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

Иногда банальные вещи трудно увидеть. Надеюсь на эту помощь.

Возможный сценарий:

иногда может случиться так, что при настройке файлов SSL (закрытый ключ и сертификат) для виртуального хоста, который настраивается, было забыто указать абсолютный путь, по которому эти файлы находятся.

Например, если вы следуете этому официальному документу от 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;
    ...
}

Предположим, вы храните файлы SSL внутри "/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

Что случается?

По умолчанию, если не указан абсолютный путь для обычного файла, который используется Nginx, Nginx будет искать файлы в "/ etc / nginx"

Из /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)

Что надо делать?

Чтобы указать абсолютный путь к дополнительным файлам, которые используются вашей конфигурацией Virtualhost.

Как это:

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;
    }

}

попробуй начать с /root :

ssl_certificate         /root/path/to/cert.crt;
ssl_certificate_key     /root/path/to/cert.pem;

Решил проблему вот так.

Радость

Я столкнулся с той же проблемой.

[символ]
он не может запуститься с "systemctl restart nginx".
но команда ниже может запустить nginx.
"/ usr / sbin / nginx"

[couse]
Я использовал файл сертификата напрямую, скачанный у провайдера.

[решено]
Я скопировал текст сертификата и вставил его в созданный мной файл (с помощью vim).

Я была такая же проблема. Мне пришлось изменить Файлы / etc / nginx / sites-enabled / default и default.save которые были автоматически добавлены имя моего сайта без .com после этого в процессе настройки, КАКОЙ БЫЛ ВЫПУСК В МОЕМ СЛУЧАЕ. Чтобы быть кратким, эти две строки нужно было изменить в моем / etc / nginx / sites-enabled / default. Обратите внимание, что этот файл отображается со значком ярлыка в моей файловой системе, но я смог щелкнуть файл правой кнопкой мыши и отредактировать его с помощью параметра «Редактировать / Внутренний редактор».

HTTPS - запросы прокси к локальному Node.js ap # HTTPS - запросы прокси к локальному приложению Node.js:

server {
    listen 443;
    server_name 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;
    # ...
}

Когда я просмотрел файлы и добавил .com - соглашение об именах, которое я использовал для добавления файла, - к ссылкам switchmagic в каталогах файлов, которые выдавали ошибки, все было хорошо! Я обнаружил, что множество разработчиков задают тот же вопрос, поэтому я хотел предложить свое решение, чтобы помочь, поскольку ответы, которые я нашел, в основном касались прав root, но в моем случае права root не были проблемой. Rock on Devs.