Re: any nginx/letsencrypt experts out there?
- In reply to: Waitman Gobble : "Re: any nginx/letsencrypt experts out there?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 12 Sep 2022 04:10:39 UTC
---- On Mon, 12 Sep 2022 13:21:30 +0930 Waitman Gobble wrote ---
> 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 /.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
>
>
My apologies. I don't contribute to the ML very often and completely forgot!
Ty