This happened a couple months ago as well. Is certbot misconfigured?
rDNS (209.160.32.187): lemmy.sdf.org.
Service detected: HTTP
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "server name/#0"
"EC point formats/#11" "session ticket/#35"
"status request/#5" "next protocol/#13172"
"supported versions/#43" "key share/#51"
"max fragment length/#1"
"application layer protocol negotiation/#16"
"encrypt-then-mac/#22"
"extended master secret/#23"
Session Ticket RFC 5077 hint 600 seconds, session tickets keys seems to be rotated < daily
SSL Session ID support yes
Session Resumption Tickets: yes, ID: yes
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA256 with RSA
Server key size RSA 2048 bits
Server key usage Digital Signature, Key Encipherment
Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication
Serial 04D30A06E04DFFE4B17ACA22EF9CA476394A (OK: length 18)
Fingerprints SHA1 120E588E76DA8B6C125F64639565AC740421BFB9
SHA256 1469485C7ED60FA5039C1ED309659314B2464056B0590C07C14F78D252604A05
Common Name (CN) lemmy.sdf.org
subjectAltName (SAN) lemmy.sdf.org
Issuer R3 (Let's Encrypt from US)
Trust (hostname) Ok via SAN (same w/o SNI)
Chain of trust NOT ok (expired)
EV cert (experimental) no
ETS/"eTLS", visibility info not present
Certificate Validity (UTC) expired (2024-05-02 01:18 --> 2024-07-31 01:18)
# of certificates provided 2
Certificate Revocation List --
OCSP URI http://r3.o.lencr.org
OCSP stapling offered
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency yes (certificate extension)
Judging by something I posted during the outage, I think federation was affected.
Welp, it wouldn’t be wise if instances accepted invalid certificates.