2018/08/25

From Mew
< 2018
Revision as of 18:51, 20 November 2022 by Woozle (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Saturday, August 25, 2018 (#237)

Friday Saturday Sunday

prev .. today .. next

2024-11-29 (Fri) 11:19 EST Everything seems to be working ok... (details of last incident.)
There are no known issues.

from Discord

http://tootcat2.hypertwins.net/.well-known/acme-challenge/nLguP2F142gk3WBcZm4BSF86dEp6zMs8_5nmHXADpuM is returning a 404, and just quickly I can't tell where the actual file is supposed to be.
I'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.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
WoozleToday at 10:01 AM
Looking into this now.
The problem may be on the file-writing site... though I'm getting conflicting information...
Nginx is giving me the same problem Apache gives me: I can't tell what file it's trying to access in response to the URL.
WoozleToday at 11:13 AM
Okay, so... there's a Nginx directive that's not working as intended, and figuring out directive syntax is one of my major weak spots.

This:

    location ^~ /.well-known/acme-challenge/ {
            root /var/www/challenges;
        }


...seems like it's supposed to strip out the /.well-known/acme-challenge/ from the URL, and append whatever's left to /var/www/challenges.
So http://tootcat2.hypertwins.net/.well-known/acme-challenge/test.txt would result in an access to /var/www/challenges/test.txt.
But it's not; it's actually resulting in an access to /var/www/challenges/.well-known/acme-challenge/test.txt.
But this is a location I can work with, so I'm not going to try to understand the location directive beyond noting that this is how it is effectively working.
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't do that; it leaves the files in place for diagnostic purposes.
And the most recent test files are from back in May.
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.
...but Firefox still says toot.cat's SSL expires on Aug. 28.
Maybe I have to restart nginx again?
Or restart Mastodon?
Dang, what's that command to check a cert from the CLI... openssl something, I think...
Oh good, I made notes: https://htyp.org/openssl
openssl s_client -connect toot.cat:443 -- okay, great, gives me lots of info that does not include the expiration date.
The secret code phrase is apparently: echo | openssl s_client -connect toot.cat:443 2>/dev/null | openssl x509 -noout -dates
...and this confirms that the expiry is still 3 days from now.
WoozleToday at 12:01 PM
Got it.
I'm not sure if Let's Encrypt will renew properly next time, though; the config was clearly kind of messed up. I tried to tidy it, but I'm guessing about some pieces.