0

I have nginx which I'm using mainly as a reverse proxy. I have many services running at home such as Plex. It is reachable through plex.mydomain.com for which I have created a letsencrypt certificate. Everything was working perfectly until I have updated the letsencrypt certificates. Since then, only my desktop Chrome still works but I'm suspecting it is doing so because of its cache. Safari does not work, neither curl nor wget.

The nginx conf is the following

server {
        listen                  80 ;
        server_name  plex.mydomain.com plex.myotherdomain.com ;
        rewrite ^ https://$server_name$request_uri? permanent;
}
server {
        listen        443;
        server_name  plex.mydomain.com plex.myotherdomain.com ;
        satisfy any;
        allow 192.168.1.0/24; ##chez moi
        deny all;
        auth_basic "closed site";
        auth_basic_user_file /etc/nginx/certs/password;
        ssl_certificate /etc/letsencrypt/live/plex.mydomain.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/plex.mydomain.com/privkey.pem;


        location / {
            proxy_pass        http://192.168.1.102:5000;
            proxy_redirect http:// $scheme://;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;

    }
}

If I run curl https://plex.mydomain.com then I get curl: (56) SSLRead() return error -9806.

When I access plex.mydomain.com from Safari, Nginx logs give

2016/08/09 19:23:27 [alert] 52081#0: worker process 53076 exited on signal 11
2016/08/09 19:23:27 [notice] 52081#0: start worker process 53079
2016/08/09 19:23:27 [notice] 52081#0: signal 23 (SIGIO) received
2016/08/09 19:23:27 [notice] 52081#0: signal 23 (SIGIO) received

The letsencrypt certificate has been generated with the following command:

sudo certbot certonly --standalone -d plex.mydomain.com -d plex.myotherdomain.com

Any idea what am I doing wrong? Thank you very much for your help.

radar
  • 500
  • 1
  • 6
  • 24
  • Looks like it may be an issue with the OS X supplied version of cURL: http://stackoverflow.com/questions/26461966/osx-10-10-curl-post-to-https-url-gives-sslread-error – robertklep Aug 10 '16 at 07:58
  • But Safari does not work neither, as well as iOS Chrome. I suspect Chrome desktop still working because of some cache. – radar Aug 10 '16 at 14:26
  • Sorry, missed that, although fixing the cURL issue might provide you with more info on why it's failing. What are the errors that you're getting in Safari/iOS Chrome? – robertklep Aug 10 '16 at 14:30
  • Safari cannot open the webpage (similar to 404). iOS Chrome returns `ERR_SSL_PROTOCOL_ERROR`. – radar Aug 10 '16 at 15:15
  • Does `openssl s_client -connect plex.mydomain.com:443` provide any info? – robertklep Aug 10 '16 at 16:11
  • Yes, it gives info and some hints. It shows that it is not the certificate of that subdomain which is sent but another one. I created another certificate for nas.mydomain.com and it is this one one which is provided by the server. And I can't figure out why. One main message is the following `verify error:num=20:unable to get local issuer certificate` which refers to a missing a root certificate. – radar Aug 10 '16 at 20:23
  • Actually, I have several services running, each with its own ssl certificate. And each service has its own server block for nginx conf and it seems nginx is serving the certificates by alphabetical order... If I delete the nas service, then nginx is serving owncloud certificate but if I disable owncloud too then it serves plex certificate for each ssl service. – radar Aug 10 '16 at 20:45

1 Answers1

0

I fixed the issue by generating a new certificate where I mentioned the root domain name too. The whole command is then certbot certonly --standalone -d mydomain.com -d myotherdomain.com -d plex.mydomain.com -d plex.myotherdomain.com

And now, it works like a charm. Thank you guys for your help.

radar
  • 500
  • 1
  • 6
  • 24
  • This was the issue for me. While trying to set up an SSL on my subdomain, without a valid working one for the root domain it just wouldn't work. – Lewis Aug 20 '23 at 12:33