Re: any nginx/letsencrypt experts out there?

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/http://www.paulbeard.org/fullchain.pem; # managed by Certbot

    ssl_certificate_key /usr/local/etc/letsencrypt/live/http://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  http://www.paulbeard.org http://paulbeard.org;

    server_name  http://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/http://paulbeard.org/fullchain.pem; # managed by Certbot

    ssl_certificate_key /usr/local/etc/letsencrypt/live/http://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  http://paulbeard.org;

    rewrite ^(.*) https://www.paulbeard.org$1 permanent;

    #return      301 



    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 http://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 <mailto:ty-ml@eye-of-odin.com> wrote:








-- 

Paul Beard / http://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 <http://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 http://www.mydomain.com -d http://cloud.mydomain.com -w /usr/share/nginx/html


















---- On Mon, 12 Sep 2022 10:27:09 +0930 paul beard <mailto: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 / http://www.paulbeard.org/