• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion
  • Please beaware of a breaking change in the REST API on the current Plesk release (18.0.62).
    Starting from Plesk Obsidian 18.0.62, requests to REST API containing the Content-Type header with a media-type directive other than “application/json” will result in the HTTP “415 Unsupported Media Type” client error response code. Read more here

Question Strange SNI (?) issue related to IPv6 (?)

Carbon Dioxide

New Pleskian
Hello everyone,

I am not a Plesk user, however I am a software developer who stumbled into a very weird bug that looks like it may be caused by some Plesk misconfiguration, on some websites I tried to visit.

I did a bit of a deep dive to satisfy my curiosity. I am fully aware that one thing to do here is to contact the administrators of the affected websites, but I wanted to ask about it here as well just to see if this is a known issue, or if I've perhaps found some bug in Plesk.

I have found 2 affected sites. For one of them, I've been in touch with the administrator, he has fixed it and we have discussed possible causes.
The other one has not been fixed yet. I will try to contact them after I get some responses here, because having the bug live will make it easier for you to see the problem.

The still-affected website is www.kanjers.nl. It is owned by a company that makes stroopwafels (Dutch cookies).

If you go to this page, either it loads like normal and you go to the intended page.
Or, you get an SSL cert error saying the certificate is valid for a Plesk domain only and not for kanjers.nl. If you bypass the cert error, it takes you to this landing page:

5EmKkgM.png


From the best me and some friends can tell, the error where it takes you to this landing page only occurs if the user is on a fully IPv6 capable connection ( 10/10 score on Test your IPv6. ). This corresponds to what the website admin of the now fixed website said: He had recently added an IPv6 rule to his domain and after he removed that, the problem was fixed.

The fact that I found this issue on two separate websites in a couple weeks time makes me worried that it's very easy to trigger and hard to notice for website admins.

The actual cause seems more subtle than "just" an IPv6 connectivity issue.

On my affected connection, if I do a DNS lookup for www.kanjers.nl I get 93.119.2.4. This matches what unaffected people get.
Then, I am able to both reproduce and solve the problem by doing some connection trickery directly using this IPv4 address:

Running openssl s_client -host 93.119.2.4 -port 443 on my Linux command line gives me:
Code:
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = server.cisc.one
verify return:1
Which is the wrong cert.

openssl s_client -host 93.119.2.4 -port 443 -servername www.kanjers.nl, instead returns:
Code:
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = kanjers.nl
verify return:1

This is the correct cert for kanjers.nl. This shows that something must be up with SNI (Server Name Indication).

One more part to this, if I do a HTTP request on this open SSL connection (regardless of whether I use the -servername param or not), I can force to load the intended page by using the correct http Host header:

Code:
GET / HTTP/1.1
Host: www.kanjers.nl

If I use anything else than this Host header, a Plesk page is returned that is not supposed to show to the end user.

Well, that's all I found.

I hope this was the right place to ask about this. I am curious to see what you think.
 
Last edited by a moderator:
It's hard to say for sure without knowing the specific server configuration and domain settings used, but I suspect that they (whoever manages the server of this domain) did not assign an IPv6 address to the domain. While they did configure AAAA (IPv6) DNS records for the domain. So when making a IPv6 request for the domain, the default server index page gets returned.

A simple, but yet serious, configuration oversight.

On my affected connection, if I do a DNS lookup for www.kanjers.nl I get 93.119.2.4. This matches what unaffected people get.
Then, I am able to both reproduce and solve the problem by doing some connection trickery directly using this IPv4 address:

Running openssl s_client -host 93.119.2.4 -port 443 on my Linux command line gives me:
Code:
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = server.cisc.one
verify return:1
Which is the wrong cert.
That would be expected. When there is no servername specified the default server certificate would be used.
 
Thanks. The owner of the other website confirmed your suspicion about not assigning an IPv6 address.

I have just informed the owners of www.kanjers.nl as well.
 
Back
Top