Wrong cert on every cloudflare domain if the optional "." at the end of a FQDN is supplied - rfc3986

I raised this as a support ticket and was directed to post it in the community forum. Hopefully this is the correct place.

From rfc 3986 (rfc3986):

The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single “.” and should be if it is necessary to distinguish between
the complete domain name and some local domain.

https://jakechampion.name returns correct certificate
https://jakechampion.name returns incorrect certificate

This is present on all the cloudflare hosted sites I’ve tried, including https://cloudflare.com./

The main thing I noticed from the wrong certificate, it is does not list any ciphers.

This openssl command contains more information about the wrong certificate being served:

openssl s_client -servername jakechampion.name. -connect jakechampion.name.:443 -tlsextdebug
CONNECTED(00000005)
4516851308:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.140.1/libressl-2.8/ssl/ssl_pkt.c:1200:SSL alert number 40
4516851308:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.140.1/libressl-2.8/ssl/ssl_pkt.c:585:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1621423898
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

I am afraid you are confusing SNI with FQDN here.

While a trailing dot in an FQDN is permitted and stands for the root of DNS, it actually is not for SNI

“HostName” contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot.

RFC 6066

In your DNS query you can use as many dots as you wish :slight_smile: and it will resolve fine but if you use a trailing dot in your SNI you will specify a wrong hostname and hence Cloudflare can’t return the right certificate.

The following will work

openssl s_client -servername jakechampion.name -connect jakechampion.name.:443

Thanks @sandro, do you know why the requests serve the wrong cert when made from a browser?

My best guess would be browsers do not sanitise/normalise the SNI field and take the exact value from the hostname and that will break for aforementioned reason. I actually only tried Firefox, where I could reproduce that behaviour, and cannot comment on the others (which others, there’s only Blink at this point :smile:). For Firefox there’s actually a bug report - 134402 - URLs with trailing dots in host names (FQDN) produce cert name mismatches - which is 19 years old.

It’s actually not even a wrong certificate, but rather none at all, as that hostname is unknown on an SSL level and hence no certificate is found either.

In short, avoid trailing dots :slight_smile: - while they are accepted on a DNS level they could possibly be a problem there too.

Yeah, it seems to not work for any cloudflare domains but does work for domains on other systems such as Fastly - E.G. https://www.ft.com./ returns the correct certificate and is served by Fastly

Oh, I can confirm that ft.com. and wikipedia.org. both work on Firefox on OSX, I think that bug might be outdated

Considering that cloudflare.com. does not I assume the browser still sends the trailing dot but Wikipedia is more lenient and either accepts the invalid SNI or uses a default certificate.

Probably best to ask Google to fix this as well!

1 Like

Yeah, but that won’t be the sysadmins in that case (isn’t that called SRE in newspeak?) but rather Chrome’s team. Add Apple to that jolly mix as well, as Safari believes in trailing dots too.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.