Thanks guys. Using -servername does return correct server. Apparently macOS monterey's openssl is old. I could have sworn that I recently got LE details without -servername but must have been from a different OS.
I'm still fighting the fight with Palo and Slack. Someone will give.
Maybe you could trick it... into submission!
Setup a inverse/reverse proxy to hide the slack site from Palo's direct sight.
[this may require using DNS/proxies/NAT/etc. in ways that may reshape the time continuum - LOL]
Could be connecting to a server (not a CDN) that only has a Let's Encrypt certificates and no others, in which case the default no-SNI certificate would be the one issued by Let's Encrypt.
That would cut off a giant chunk of the internet's users, with disproportionate effects based on class and geopolitical regions.
The history of the "Long Chain Solution" includes most of the browser, os, and SSL projects coming together to loosen restrictions and coalesce around making the "short circuit" chain validation logic the standard default. A lot of key players in the greater internet industry came together for this solution. It is unfortunate that Palo Alto decided not to join everyone else.
IMHO, Palo Alto makes subpar products without much thought or foresight. They are notorious in this forum (as some comments above indicate) for randomly implementing rules that block authentication without adequately notifying their customers, if at all.
Will those users be perpetually permitted to use the expired / unsafe cert? Or were they just given extra time before they will actually be cut off in 2024?
I'm not sure why they expire to begin with, although Android is one of the few ecosystems out there not enforcing the expiry of a trust anchor.
Fun fact: OpenSSL doesn't even check the signature of a root certificate! The trust anchor in a root certificate store is ultimately trusted, even if you modify the certificate. See Working around expired Root Certificates for more info.
All certs [including root certs] must have a start and an end date.
So, eventually that end date will come to pass.
That said, the end date for root certs are not applied like end dates for all other certs; Some operating systems/browsers will ignore the end date for root certs [and some won't].
4.1.2.5. Validity
To indicate that a certificate has no well-defined expiration date,
the notAfter SHOULD be assigned the GeneralizedTime value of
99991231235959Z.
which would nomally mean dec 31th midnight in year 9999