Date: Mon, 12 Sep 2022 03:51:30 +0000 From: Waitman Gobble <gobble.wa@gmail.com> To: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: any nginx/letsencrypt experts out there? Message-ID: <CAFuo_fwRcLRaSb9bDOe3BV_W0dUkbAjL3_P=TpifYQrxjXD5rQ@mail.gmail.com> In-Reply-To: <1832f85d371.10bae82d3411853.462587170353998748@eye-of-odin.com> References: <CAMtcK2reN%2BDGjvdaJJ=3ppz4uK0RU8gJ1f4BY1kvJ%2B5xHqgOsg@mail.gmail.com> <1832f40c8af.10b332ee2406187.6375306777861801560@eye-of-odin.com> <CAMtcK2oo_5vS8AAyd6jPgniggKvYNWbiJwpQZvPb5yeAPENJGA@mail.gmail.com> <1832f85d371.10bae82d3411853.462587170353998748@eye-of-odin.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 f= irst 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 s= afari? > > > > > ---- 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= =E2=80=A6logically I think the bare non-www should be first, and redirect t= o 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 /wordp= ress is handled. > > server { > > listen 443 ssl http2; > > listen [::]:443 ssl http2; > > ssl_certificate /usr/local/etc/letsencrypt/live/www.paulbeard.org/ful= lchain.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=3D15552000; includeSubD= omains" 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/fullcha= in.pem; # managed by Certbot > > ssl_certificate_key /usr/local/etc/letsencrypt/live/paulbeard.org/pri= vkey.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=3D15552000; includeSubD= omains" 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 =3D @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 comma= nd 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 meth= od where letsencrypt checks the <yourdomain.com>/.well-known/foobar on port= 80. Automation works much better by specifying multiple domains on a singl= e cert with the subsequent domains being SANs. > > For example, I use acme.sh. You can use as many -d options as you like an= d they will be added as SANs to a single certificate. > > acme.sh --issue -d www.mydomain.com -d cloud.mydomain.com -w /usr/share/n= ginx/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 insta= llation. 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 wit= h from reading nginx.conf (ie, it was setup and worked that way but might h= ave always been wrong and I am just now catching up with that). The cloud.d= omain server loads just fine but the www.domain will not. There is addition= al 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. ar= e 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 cha= nce 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. --=20 Waitman Gobble
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFuo_fwRcLRaSb9bDOe3BV_W0dUkbAjL3_P=TpifYQrxjXD5rQ>