On 11.10.22 17:46, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:
ok according to https://www.openssl.org/docs/man1.0.2/man5/x509v3_config.html SAN is not a valid option along with CN
... I don't see that being said in the page you refer to?
Anyhow, "stop giving a CN, use SANs instead" is a rather recent development coming from the CA/Browser Forum - and IIUC still not a *requirement*, not even for web browsers/servers. I would be surprised if OpenSSL (already) were trying to enforce that policy.
Hmmm, what's our company's "IMAPS server" throwing at my TB again ... ?
$ openssl s_client -connect outlook.office365.com:993 -showcerts | openssl x509 -noout -text [...] Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com [...] X509v3 Subject Alternative Name: DNS:*.clo.footprintdns.com, DNS:*.hotmail.com, DNS:*.internal.outlook.com, [...]
... yeah, no, nothing that Thunderbird (from 69-ish to 102) should get indigestion over.
Upoin further testing thunderbird seems to be locking onto the primary domain (*.scom.ca) of the server skipp any sni setup ??
You might want to get a network trace of your Thunderbird talking to the server to see what cert actually is presented by the server, and ideally, what domain is requested by SNI (if at all). That all happens before the connection starts to be encrypted, so you should be able to read it (say, with Wireshark) without having to crack any crypto ...
Kind regards,
Jochen Bern Systemingenieur
Binect GmbH