[haertig]

I have moved forward a bit and gotten HTTPS working with the NGINX reverse proxy for the Content Server.

And I have gotten the "require client cert for authentication" working too. So now my Content Server is nice and secure. NGINX will not let anyone past the front gate until they provide a client cert that I have personally signed.

Next step is for me to turn OFF the Content Server's "Require username and password to access the content server" checkbox. But if I do that, this will apparently also disable the user config setting of "Allow guest to make changes (i.e. grant write access?)" BTW, "guest" is the name of the user profile I previously set up.

I don't want anybody to be able to make changes via the Content Server, but it appears that the only way to prohibit this is to configure user profiles, which is what I was just trying to turn off. So I looked around in the Content Server web user interface, and I cannot find anything, anywhere, where the user could change anything. So if I were to "grant write access" (which I don't want to do anyway), what exactly would I be granting them access to do? I can't find anything available for writing. Or is this setting reserved for potential future use only, and has no effect in the current implementation?

FWIW, here are the server blocks I am using in NGINX to accomplish all this:

        server {
                listen 80;
                return 301 https://$host$request_uri;
        }

        server {
                listen 443 ssl http2;
                server_name my.domain.name localhost 10.192.0.26 default_server;
                root /var/www;

                ssl_certificate /etc/letsencrypt/live/my.domain.name/fullchain.pem;
                ssl_certificate_key /etc/letsencrypt/live/my.domain.name/privkey.pem;
                ssl_client_certificate /etc/ssl/certs/ca.crt;
                ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
                ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!AES128';
                ssl_ecdh_curve secp384r1;
                ssl_prefer_server_ciphers on;
                ssl_stapling off;
                ssl_stapling_verify off;
                ssl_session_timeout 24h;
                ssl_session_cache shared:SSL:50m;
                ssl_session_tickets off;
                ssl_verify_client optional;

                location /calibre {
                        if ($ssl_client_verify != SUCCESS) {
                                return 403;
                        }
                        proxy_buffering off;
                        proxy_set_header X-Forwarded-For $remote_addr;
                        proxy_pass http://10.192.0.2:8080$request_uri;
                }
        }

Next up, is to review my SSL settings (the ciphers that I specified, other stuff, etc.) to make sure that is solid and secure before turning this loose on the open internet.