3 ms·
It seems that the server running on the other end doesn't properly match the certificate from the SNI if the domain sent by the browser is a FQDN (i.e. ends in
by internalthief 7y ago
It seems that the server running on the other end doesn't properly match the certificate from the SNI if the domain sent by the browser is a FQDN (i.e. ends in a .)
For example, try the following:
openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk."
vs
openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk"
You'll notice that in the first case the default certificate is sent back, in the second case the certificate is correctly matched against the SNI.
According to the Server header returned:
Server: Apache/2.4.41 (cPanel) OpenSSL/1.1.1d mod_bwlimited/1.4 Phusion_Passenger/5.3.7
Testing against an NGINX based server, I am not seeing the same results, in fact I am seeing the correct certificate being returned.
- tialaramex 7y agoThe relevant RFC says not to send a trailing dot in SNI. Browsers should probably trim the dot out if present. Maybe they aren't doing so because it causes some unexpected compatibility mishap, maybe in reality it rarely causes any trouble so nobody got around to it.
- internalthief 7y agoI was not aware of this!
- jwilk 7y agohttps://tools.ietf.org/html/rfc3546#section-3.1 https://tools.ietf.org/html/rfc3546#section-3.1 > "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using UTF-8 encoding, without a trailing dot.