Hi All,
This is only tangentially related to OpenBSD...
My web server is running OpenBSD 6.8 (yes, I know) using apache2 and
letsencrypt certificates.
I'm getting reports from one of my domain hosting clients (mt43news.com)
of customers reporting intermittent SSL domain name mismatch errors on
the initial page load. So far I've only heard that this happens with
Windows using the Chrome web browser and now we have a report of the
same error from someone using an Android phone also using the Chrome
browser.
I have not been able to duplicate this here using MacOS, Ubuntu,
ChromeOS or OpenBSD and using either Firefox or Chrome.
I have seen a screenshot that clearly shows that Windows/Chrome is
trying to match the cert for another domain that I host. If the client
refreshes the web page with the domain mismatch error displayed the
error goes away and the home page for the paper is displayed as expected.
Clicking the padlock on any browser shows that my letsencrypt
certificates are indeed valid.
apache error logs do include quite a few of errors like this:
[Sun Apr 16 09:49:04.907839 2023] [ssl:error] [pid 38218] [client
167.94.138.50:48002] AH02032: Hostname mt43news.com provided via SNI and
hostname 207.158.15.156 provided via HTTP have no compatible SSL setup
This log line is from broadwatercountymuseum.com_ssl_error_log and
broadwatercountymuseum.com is the domain that's most often tried instead
of mt43news.com's. In fact, broadwatercountymuseum.com is the top name
alphabetically in the directory where the config files for ssl vhosts
are stored.
I've seen this sort of mis-match using openssl s-client:
jross@luna:/var/log/apache2 $ openssl s_client -connect mt43news.com:443
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=3 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA
Limited, CN = AAA Certificate Services
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = AT, O = ZeroSSL, CN = ZeroSSL RSA Domain Secure Site CA
verify return:1
depth=0 CN = broadwatercountymuseum.com
verify return:1
depth=0 CN = broadwatercountymuseum.com
However, if I add -servername to allow for SNI it works correctly:
jross@luna:/var/log/apache2 $ openssl s_client -servername mt43news.com
-connect mt43news.com:443
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=3 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA
Limited, CN = AAA Certificate Services
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = AT, O = ZeroSSL, CN = ZeroSSL RSA Domain Secure Site CA
verify return:1
depth=0 CN = mt43news.com
verify return:1
depth=0 CN = mt43news.com
I want to pin all this on Chrome since the client is tasked with sending
the servername at the beginning of the handshake. I wonder if Chrome is
starting this handshake without specifying a servername? If that was
the case though I'd expect the problem to appear way more often that it
does.
https://stackoverflow.com/questions/27772133/apache2-error-hostname-provided-via-sni-and-http-do-not-match
This is going to be a real problem for the paper in a couple of months
when subscribers start trying to log into the web site to renew their
subscriptions so it's something I really need to fix (if I can).
If anyone else out there is getting this error or has gotten this error
and figured out a workaround I'd love to hear from you, either on or off
list.
If you made it this far thanks for reading!
Jeff Ross
