X2-valid testing page without SNI serves X1 chain

Site Feedback
1

I don't know if that's intentional or a problem but I was doing some much older openssl s_client testing for a legacy system against https://valid-isrgrootx2.letsencrypt.org/ and I noticed it would provide the X1 chain because I forgot to include SNI.

The SSL Labs report is probably easiest to convey: SSL Server Test: valid-isrgrootx2.letsencrypt.org (Powered by Qualys SSL Labs)

3 Likes
2

Thanks for the report. That site and several others are hosted by the same webserver on a single IPv4 address, so it relies on SNI/ALPN to select the correct chain to send.

We'll talk internally about considering acquiring some additional IPv4 addresses.

6 Likes
3

Np. I believe badssl.com does the same with the same IP address and using SNI for different certs, but with the TLS protocol tests it uses different ports, so that might be an option too instead of multiple IP addresses.

Only other thing that I thought would be nice was test pages for cross-signed roots vs. not cross-signed roots, or whichever combos of LE chains could reasonably configured. Such as the upcoming DST Root CA X3 switch.

Others could be X2 issuer as X1 and X2 self-signed, less so would be testing the backup intermediates R4 and E2.

Thanks!

3 Likes
4

You don't necessarily need extra IPv4 addresses, you can also just not answer to non-SNI requests (which should be virtually non-existent today, except things like "openssl s_client").

For example with nginx this can be achieved by using ssl_reject_handshake in the default vhost, it will terminate the SSL handshake with "unrecognized name".

9 Likes
5

We deployed this about an hour ago, actually. It's a good idea. :slight_smile:

8 Likes
6

Modern s_client even sends SNI by default :slight_smile:

I think that landed in 1.1.1

4 Likes