I am running nginx 1.11.3, compiled from source with the addition of the ngx_cache_purge module, on Ubuntu 14.04.3 server.

I'm seeing in the nginx error.log the following:

2016/08/03 14:30:00 [warn] 21827#21827: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2016/08/03 14:30:00 [emerg] 15611#15611: BIO_new_file("/etc/letsencrypt/live/XXXXXXX.com/fullchain.pem") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/XXXXXXX.com/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)

The two lines always come in one after the other. The odd thing is that the site seems to be served properly, and https also seems to be working, despite it claiming in that error there (I think) that it can't read the certificate chain.

In nginx.conf, I have the first line set to: user www-data www-data;

If I do ps aux | grep nginx, I see that the master process IS running as root, and the worker and cache processes as www-data -- as it should be, I think. I'm starting nginx through sudo service nginx start.

One thing I've noticed is that no matter what I've tried, OCSP stapling does not work. The only vague thought I've had is that when nginx tries to some part of the SSL negotiation, maybe it opens another process that needs to be root to access the letsencrypt/live/* directories, but that process is not being launched as root. Just a wild guess.

As for the /etc/letsencrypt directory, it is owned by root, has drwxr-xr-x set, live and archive subdirs set to drwx------, individual site folders within those set to drwxr-xr-x. Individual symlinks to keys/certs in live are set to lrwxrwxrwx and the actual keys/certs in archive are set to -rw-r--r--

There is one other question about this, but it went unanswered.

nginx -V output in case it is useful:

nginx version: nginx/1.11.3 built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) built with OpenSSL 1.0.2h 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-module=/opt/nginx_cachepurge_module/ngx_cache_purge --add-dynamic-module=debian/extra/njs-0.1.0/nginx --with-threads --with-stream --with-stream_ssl_module --with-stream_geoip_module=dynamic --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'


You should make your private keys readable by ssl-cert group. Try

sudo chown -R root:ssl-cert /etc/letsencrypt/live/XXXXXXX.com/
  • This on its own hasn't changed anything. It seems like nginx can read the key/cert to some extent since, as I mentioned, https on the site is working. But when the site is visited, these errors are generated in the logs, and -- maybe related -- OCSP stapling does not work. – Josh K Aug 3 '16 at 21:26
  • Ok, just to be clear - if you set 755 permissions on certificate folder - everything works fine, right? We are talking about keeping secure permission like 600 and owner root on certificates? (and not about certificates not working at all, right?) – Anubioz Aug 3 '16 at 21:31
  • That didn't work and led to different errors, but did lead me to the real source of the problem, which I've posted. Thank you. – Josh K Aug 4 '16 at 0:12

I figured this out. For some of its https negotiation -- I think only the first https negotiation of each server block after nginx starts up -- nginx spins up a temporary root-user process that is then immediately closed as soon as the negotiation. For me, this was failing because I compiled nginx myself after previously having the repository version installed. Though I removed the standard version with apt-get remove before installing my own compiled nginx, some part of the original's startup script was left behind, and when my new nginx was trying to spin up that process (and it seems only that process, no other part), it was failing. I solved by doing a complete apt-get remove --purge and then reinstalling my compiled version.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.