0

Very similar to this question but the solutions there did not solve my problem.

I am trying to reverse proxy port 8443 to port 4000 with a self signed certificate. I generated my certificate like this

openssl req -newkey rsa:2048 -sha256 -nodes -keyout certificate.key -x509 -days 365 -out certificate.pem

And I added a server block to my nginx conf:

server {
  listen 8443 ssl;
  server_name www.mydomain.io;
  ssl_certificate /home/user/certificate.pem;
  ssl_certificate_key /home/user/certificate.key;

  location / {
    proxy_pass http://localhost:4000/;
  }
}

But now when I try to start nginx with systemctl start nginx I get the following error:

Sep 10 06:38:52 Elixir systemd[1]: Starting The nginx HTTP and reverse proxy server...
Sep 10 06:38:52 Elixir nginx[25347]: nginx: [emerg] BIO_new_file("/home/user/certificate.pem") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/home/user/certificate.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)
Sep 10 06:38:52 Elixir nginx[25347]: nginx: configuration file /etc/nginx/nginx.conf test failed

Edit: The files have 777 permissions but are not owned by the nginx user.

RusinaRange
  • 11
  • 1
  • 5
  • A very strong convention for services is to have their settings and configuration files in `/etc/` and not in your home directory. Second the first thing to investigate in a `fopen ... permission denied` type error are indeed the file system permissions for both the file and complete directory path as they apply to whatever user nginx runs as. ( your users home directories are typically closed to other users...) – HBruijn Sep 10 '16 at 07:30
  • I forgot to add that I made the .key and .pem files have 777 permissions – RusinaRange Sep 10 '16 at 07:32
  • 777, That's too much! And. .. You also need to check the permissions on the **full directory path** I.e. `/home/ & /home/user/` and not just those on the certificate and key.. – HBruijn Sep 10 '16 at 07:35
  • Move didn't solve my problem. If it is for the full path wouldn't nginx have to belong to the root group? Permissions for /etc/ `drwxr-xr-x root root etc`. – RusinaRange Sep 10 '16 at 08:09
  • nvm, It does have read access for everyone. Move + the other questions answers still didn't solve my problem though. – RusinaRange Sep 13 '16 at 07:22

2 Answers2

1

A very strong convention for services is to have their settings and configuration files in /etc/ and not in your home directory.

Second the first thing to investigate in a fopen ... permission denied type error are indeed the file system permissions for both the file and complete directory path as they apply to whatever user nginx runs as.

(Users home directories are typically closed to other users...)

Use namei to display the permissions of the full path:

namei -mov /home/user/certificate.pem

If the normal file system permissions are correct, then investigate further into for instance SELinux access controls as explained in the Q&A you linked to.

HBruijn
  • 77,029
  • 24
  • 135
  • 201
1

This problem was very likely due to selinux labeling the file as something insecure like unconfined_u therefore denying access to it no matter what the permissions of the file are. The labels for a file can be checked by running ls -Z.

The solution is to change the label (aka selinux context) of the file to something that nginx permitted to open:

chcon -t httpd_config_t /path/to/file
RusinaRange
  • 11
  • 1
  • 5
  • 1
    The answer is correct. I would anyway mention that this is "runtime" solution. With the first `restorecon` the changes will be reverted... To make it persistent you should add _record_ to fcontext using `semanage fcontext -a -t httpd_config_t /path/to/file` and then you can run `restorecon -R -v /path/to/file` to apply the changes. In case you have already use `chcon` you don't need to run `restorecon` as it is already set up. The `semanage fcontext...` is the part making it persistent. – Kamil J Feb 27 '19 at 15:22