Re: any nginx/letsencrypt experts out there?

On Mon, Sep 12, 2022 at 2:42 AM Ty John <ty-ml@eye-of-odin.com> wrote:
>
> That order should be fine. The more specific locations should be listed first which is what you have. The redirect will trigger a new request which will match the first stanza.
>
> Anyway, it looks fine to me as long as the certs themselves are right.
> I just checked the certs on https://paulbeard.org, https://www.paulbeard.org and https://cloud.paulbeard.org and they all seem fine to me.
> I suspect it might be a browser issue as you mentioned. What happens in safari?
>
>
>
>
> ---- On Mon, 12 Sep 2022 10:53:29 +0930 paul beard <paulbeard@gmail.com> wrote ---
>
> I am using certbot renew for renewals.
>
> This is part of the stanza for the www. listener. Not sure why it's first…logically I think the bare non-www should be first, and redirect to this but I never said I knew what I was doing. At the moment, all is well at the root level but I seem to have buggered something up with how /wordpress is handled.
>
> server {
>
>     listen 443 ssl http2;
>
>     listen [::]:443 ssl http2;
>
>     ssl_certificate /usr/local/etc/letsencrypt/live/www.paulbeard.org/fullchain.pem; # managed by Certbot
>
>     ssl_certificate_key /usr/local/etc/letsencrypt/live/www.paulbeard.org/privkey.pem; # managed by Certbot
>
>     include /usr/local/etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
>
>     ssl_dhparam /usr/local/etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
>
>
>     add_header X-Clacks-Overhead "GNU Terry Pratchett";
>
>
>     # add Strict-Transport-Security to prevent man in the middle attacks
>
>     add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
>
>
>     #server_name  www.paulbeard.org paulbeard.org;
>
>     server_name  www.paulbeard.org;
>
>     root           /usr/local/www/;
>
>
>
> This is the complete stanza for the non-www stanza:
>
>     server {
>
>     listen 443 ssl http2;
>
>     listen [::]:443 ssl http2;
>
>     ssl_certificate /usr/local/etc/letsencrypt/live/paulbeard.org/fullchain.pem; # managed by Certbot
>
>     ssl_certificate_key /usr/local/etc/letsencrypt/live/paulbeard.org/privkey.pem; # managed by Certbot
>
>     include /usr/local/etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
>
>     ssl_dhparam /usr/local/etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
>
>
>     add_header X-Clacks-Overhead "GNU Terry Pratchett";
>
>     # add Strict-Transport-Security to prevent man in the middle attacks
>
>     add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
>
>     server_name  paulbeard.org;
>
>     rewrite ^(.*) https://www.paulbeard.org$1 permanent;
>
>     #return      301 https://$host$request_uri;
>
>
>     if ($request ~* http://paulbeard.org) {
>
>     return 301 https://www.paulbeard.org;
>
>     }
>
>
>     root           /usr/local/www/;
>
>     disable_symlinks off;
>
>
> }
>
>
> and these are the currently non-op wordpress bits.
>
> location /wordpress {
>
>     try_files $uri /wordpress/index.php$is_args$args;
>
>     index index.php;
>
>     }
>
>
>
>     location /wordpress/wp-admin/ {
>
>     allow 192.168.0./24;
>
>     deny all;
>
>     try_files $uri /wordpress/wp-admin/index.php;
>
>     index index.php;
>
>     error_page 403 = @goaway;
>
>     }
>
>
>
>
> On Sun, Sep 11, 2022 at 6:12 PM Ty John <ty-ml@eye-of-odin.com> wrote:
>
>
>
> --
> Paul Beard / www.paulbeard.org/
>
>
> Can you share relevant snippets from your nginx.conf as well as the command you are using to issue/renew certs?
>
> How are you verifying after the renewal? It's OK to change to a wildcard but you won't be able to do an automatic verification such as the http method where letsencrypt checks the <yourdomain.com>/.well-known/foobar on port 80. Automation works much better by specifying multiple domains on a single cert with the subsequent domains being SANs.
>
> For example, I use acme.sh. You can use as many -d options as you like and they will be added as SANs to a single certificate.
>
> acme.sh --issue -d www.mydomain.com -d cloud.mydomain.com -w /usr/share/nginx/html
>
>
>
>
>
>
>
>
>
> ---- On Mon, 12 Sep 2022 10:27:09 +0930 paul beard <paulbeard@gmail.com> wrote ---
>
> Something seems to have gone wrong with a working nginx/letsencrypt installation. I suspect LE has changed some things while this system was running 11.4 and the update to 12.3 brought those changes to light.
>
> I have a www and cloud server under a single domain and a certificate for each. Not sure that's right but I think that's what LE/certbot came up with from reading nginx.conf (ie, it was setup and worked that way but might have always been wrong and I am just now catching up with that). The cloud.domain server loads just fine but the www.domain will not. There is additional confusion over www vs bare (non-www).domain. Again, that worked before w some rewriting and whatnot but seems not to work now. Requests for www. are now forced to the non-www listener and all the necessary bits (wordpress, etc) are in the www. server stanza.
>
> Also I can get openssl on the command line to work fine so there is a chance it's some goofy Apple Safari mishegas that needs sorting out.
>
> Is it better just have a single cert for *.domain? That makes more sense to me, not sure how this other situation came to be.
>
>
>
>
>
>
> --
> Paul Beard / www.paulbeard.org/
>
>
>
>
>


this will likely never happen:

   if ($request ~* http://paulbeard.org) {

    return 301 https://www.paulbeard.org;
    }

This request would probably never come over port 443.  I'm pretty sure
nginx would kick out the request if the request is not TLS.

IE:
400 Bad Request
The plain HTTP request was sent to HTTPS port


 I would look at your defaults for port 80 and port 443 if you are
ending up with unexpected responses.

BTW are we top posting on FreeBSD ml now? I suppose I haven't been
paying attention.


-- 
Waitman Gobble