Date: Mon, 12 Sep 2022 10:41:58 +0930 From: Ty John <ty-ml@eye-of-odin.com> To: "paul beard" <paulbeard@gmail.com> Cc: "freebsd-questions" <freebsd-questions@freebsd.org> Subject: Re: any nginx/letsencrypt experts out there? Message-ID: <1832f40c8af.10b332ee2406187.6375306777861801560@eye-of-odin.com> In-Reply-To: <CAMtcK2reN%2BDGjvdaJJ=3ppz4uK0RU8gJ1f4BY1kvJ%2B5xHqgOsg@mail.gmail.com> References: <CAMtcK2reN%2BDGjvdaJJ=3ppz4uK0RU8gJ1f4BY1kvJ%2B5xHqgOsg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_1203926_1598106987.1662945118383 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 bu= t 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 8= 0. 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 cloud.mydomain.com -w /usr/sh= are/nginx/html ---- On Mon, 12 Sep 2022 10:27:09 +0930 paul beard <paulbeard@gmail.com> wr= ote --- Something seems to have gone wrong with a working nginx/letsencrypt install= ation. I suspect LE has changed some things while this system was running 1= 1.4 and the update to 12.3 brought those changes to light.=C2=A0 I have a www and cloud server=C2=A0under 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 migh= t have always been wrong and I am just now catching up with that). The clou= d.domain server loads just fine but the www.domain will not. There is addit= ional confusion=C2=A0over www vs bare (non-www).domain. Again, that worked = before=C2=A0w some rewriting and whatnot but seems not to work now. Request= s=C2=A0for www. are now forced to the non-www listener and all the necessar= y bits (wordpress, etc) are in the www. server stanza.=C2=A0 Also I can get openssl on the command line to work fine so there is a chanc= e it's some goofy Apple Safari mishegas that needs sorting out.=C2=A0 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.=C2=A0 --=20 Paul Beard / http://www.paulbeard.org/ ------=_Part_1203926_1598106987.1662945118383 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>= <meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"></h= ead><body ><div style=3D"font-family: Verdana, Arial, Helvetica, sans-serif= ; font-size: 10pt;"><div>Can you share relevant snippets from your nginx.co= nf as well as the command you are using to issue/renew certs?<br></div><div= ><br></div><div>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 multipl= e domains on a single cert with the subsequent domains being SANs.<br></div= ><div><br></div><div>For example, I use acme.sh. You can use as many -d opt= ions as you like and they will be added as SANs to a single certificate.<br= ></div><div><br></div><div>acme.sh --issue -d <a target=3D"_blank" href=3D"= http://www.mydomain.com">www.mydomain.com</a>; -d cloud.mydomain.com -w /usr= /share/nginx/html<br></div><div><br></div><div><br></div><div><br></div><di= v><br></div><div><br></div><div><br></div><div><br></div><div class=3D"zmai= l_extra_hr" style=3D"border-top: 1px solid rgb(204, 204, 204); height: 0px;= margin-top: 10px; margin-bottom: 10px; line-height: 0px; display: none;"><= br></div><div class=3D"zmail_extra" data-zbluepencil-ignore=3D"true" style= =3D"clear: both;"><div><br></div><div id=3D"Zm-_Id_-Sgn1">---- On Mon, 12 S= ep 2022 10:27:09 +0930 <b>paul beard <paulbeard@gmail.com></b> wrote = ---<br></div><div><br></div><blockquote style=3D"margin: 0px;"><div><div di= r=3D"ltr"><div>Something seems to have gone wrong with a working nginx/lets= encrypt installation. I suspect LE has changed some things while this syste= m was running 11.4 and the update to 12.3 brought those changes to light.&n= bsp;<br></div><div><br></div><div>I have a www and cloud server under = a single domain and a certificate for each. Not sure that's right but I thi= nk 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 no= w catching up with that). The cloud.domain server loads just fine but the w= ww.domain will not. There is additional confusion over www vs bare (no= n-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. s= erver stanza. <br></div><div><br></div><div>Also I can get openssl on = the command line to work fine so there is a chance it's some goofy Apple Sa= fari mishegas that needs sorting out. <br></div><div><br></div><div>Is= it better just have a single cert for *.domain? That makes more sense to m= e, not sure how this other situation came to be. <br></div><div><br></= div><div><br></div><div><br></div><div><br></div><div><div><br></div><div><= br></div><div>-- <br></div><div dir=3D"ltr" class=3D"x_1027132116gmail_sign= ature">Paul Beard / <a href=3D"http://www.paulbeard.org/" target=3D"_blank"= >www.paulbeard.org/</a><br></div></div></div></div></blockquote></div><div>= <br></div></div><br></body></html> ------=_Part_1203926_1598106987.1662945118383--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1832f40c8af.10b332ee2406187.6375306777861801560>