https://htyp.org/mw/index.php?action=history&feed=atom&title=User%3AWoozle%2Ftoot.cat%2F2018%2F08%2F25 2026-07-01T04:48:54Z Revision history for this page on the wiki MediaWiki 1.45.3 https://htyp.org/mw/index.php?title=User:Woozle/toot.cat/2018/08/25&diff=24117&oldid=prev 2018-08-25T16:20:27Z

<p>Created page with &quot;==from Discord== &lt;poem&gt; http://tootcat2.hypertwins.net/.well-known/acme-challenge/nLguP2F142gk3WBcZm4BSF86dEp6zMs8_5nmHXADpuM is returning a 404, and just quickly I can&#039;t tell...&quot;</p> <p><b>New page</b></p><div>==from Discord==<br /> &lt;poem&gt;<br /> http://tootcat2.hypertwins.net/.well-known/acme-challenge/nLguP2F142gk3WBcZm4BSF86dEp6zMs8_5nmHXADpuM is returning a 404, and just quickly I can&#039;t tell where the actual file is supposed to be.<br /> I&#039;ll look at it later, hopefully in a couple of hours, if I get a chance, but thought I should give you a heads-up just in case.<br /> Saving debug log to /var/log/letsencrypt/letsencrypt.log<br /> WoozleToday at 10:01 AM<br /> Looking into this now.<br /> The problem may be on the file-writing site... though I&#039;m getting conflicting information...<br /> Nginx is giving me the same problem Apache gives me: I can&#039;t tell what file it&#039;s trying to access in response to the URL.<br /> WoozleToday at 11:13 AM<br /> Okay, so... there&#039;s a Nginx directive that&#039;s not working as intended, and figuring out directive syntax is one of my major weak spots.<br /> This:&lt;pre&gt;<br /> location ^~ /.well-known/acme-challenge/ {<br /> root /var/www/challenges;<br /> }&lt;/pre&gt;<br /> <br /> ...seems like it&#039;s supposed to strip out the /.well-known/acme-challenge/ from the URL, and append whatever&#039;s left to /var/www/challenges.<br /> So http://tootcat2.hypertwins.net/.well-known/acme-challenge/test.txt would result in an access to /var/www/challenges/test.txt.<br /> But it&#039;s not; it&#039;s actually resulting in an access to /var/www/challenges/.well-known/acme-challenge/test.txt.<br /> But this is a location I can work with, so I&#039;m not going to try to understand the location directive beyond noting that this is how it is effectively working.<br /> The next problem is that the certbot seems to be failing to create the test file... unless it is deleting it after the test fails, but from what I remember it doesn&#039;t do that; it leaves the files in place for diagnostic purposes.<br /> And the most recent test files are from back in May.<br /> I changed the certbot config in Webmin so it points directly to /var/www/challenges/.well-known/acme-challenge/, and that seems to have worked.<br /> ...but Firefox still says toot.cat&#039;s SSL expires on Aug. 28.<br /> Maybe I have to restart nginx again?<br /> Or restart Mastodon?<br /> Dang, what&#039;s that command to check a cert from the CLI... openssl something, I think...<br /> Oh good, I made notes: https://htyp.org/openssl<br /> openssl s_client -connect toot.cat:443 -- okay, great, gives me lots of info that does not include the expiration date.<br /> The secret code phrase is apparently: echo | openssl s_client -connect toot.cat:443 2&gt;/dev/null | openssl x509 -noout -dates<br /> ...and this confirms that the expiry is still 3 days from now.<br /> WoozleToday at 12:01 PM<br /> Got it.<br /> I&#039;m not sure if Let&#039;s Encrypt will renew properly next time, though; the config was clearly kind of messed up. I tried to tidy it, but I&#039;m guessing about some pieces.<br /> &lt;/poem&gt;</div>

Woozle