Lets Encrypt Certificate #2 not trusted

Hi,
i have a root server with multiple domains. Each of those domains have independend subdomains (added under ispconfig/subdomain). Everything verifies fine (ssllabs.com -> A+) - i thought.

Some of my clients told me, that they had problems under Windows(10?) and some Versions of the Internet Explorer. There they were told that the site was not secure (typical certificate warning). If they then clicked on "load anyway", they would always end up on a subdomain. Interestingly, all customers ended up on the same subdomain (cloud.nordicalbums.com).

So I checked the certificate chain again for all of my main domains (e.g. nordicalbums.com) with ssllabs.com and there is a second certificate (for cloud.nordicalbums.com) that is delivered together with every main domain which always points to the one subdomain but is invalid.

Interestingly, this subdomain has been created by ispconfig under /sites-available/ before all other domains. Maybe this is related to it.

Here you can see it as a screenshot or check it yourself on ssllabs.com

Can you explain this? I am at the moment at a loss.
Best regards

 

For that cloud.nordicalbums.com, what does ISPConfig panel show for
Don't add to Let's Encrypt Certificate: | |

 

Thanks for your reply!
cloud.nordicalbums.com was added, as any other domain and subdomain under ispconfig->website and not subdomains or aliasdomains. Those subdomains where separate websites with their own services as nextcloud, mail, databases etc. pp. Sorry thats what i meant with "independend".

 

Thanks for your reply @Th0m

 

It is! Be aware of the "no SNI" label on the second certificate. That means that this certificate is sent to clients that do not support SNI (virtual hosts). When apache is configured with virtual hosts, these clients will get the first loaded virtual host (in your case cloud. ...). (That's also the website, that is shown when using your IP address to connect without specifying a hostname)

You can try setting the option (I have not tested this, it's on my todo-list) "SSLStrictSNIVHostCheck on", then clients without SNI support should get an error message instead of a wrong website. See https://cwiki.apache.org/confluence/display/HTTPD/NameBasedSSLVHostsWithSNI for more details.

Maybe your clients do not support TLS1.2+ ? Ask your users about their browser and exact version.

 

Please ensure all websites use either ip address or asterisk and not the mixed of both.

 

@Steini86 Thanks for your hint!
Indeed, they get an error message! Thanks. That could be a temp. solution for me. In reality, this is hardly a problem for us, because the customers with error messages are only a very small percentage. Nevertheless, it would be nice if something like this did not happen at all.

For me, the question arises why the subdomain "cloud" does not have an SNI. When I have the subdomain checked by ssllabs, one and the same certificate suddenly has SNI. Strange or?

@ahrasis yep. All Domains have the korrekt IPv4 and IPv6 in their settings.

@Th0m Have a look at my attachment. Thanks for your help!

 

@Th0m Sorry, i'm too slow. See my last post.

 

Just to illustrate the problem:
A user wants to go to cloud.domain.com. The browser will do a DNS request on cloud.domain.com and get an IP address back. The browser will connect to that IP address (not the domain!) and request the webpage. A SNI capable browser will additionally send the information that it wants to connect to cloud.domain.com and Apache will serve the vhost that matches this domain. If that domain does not exist, it will serve the first configured vhost (this happens for example, when you have configured a wildcard-DNS and someone tries to connect to nonexistent.subdomain.domain.com).
On the other hand, a non-SNI capable browser will only connect to the IP and request a webpage (this is from the last millennium where one webserver did only serve one webpage). Apache does not know which domain (vhost) and will serve the first configured.

You have basically three options to avoid this problem with non-SNI capable clients (although they should slowly become extinct):

1. Make your main site the default (problem with other domains will still exist)
2. Use a (wildcard) certificate which is valid for all your (sub)domains. Then the client will always get a valid certificate (might still get the wrong website, though)
3. Have a dedicated IP address for your main site that only hosts this site (basically not using SNI). While this is easy with IPv6 where you have practically unlimited IPs, an additional IPv4 address will cost you extra. And clients not capable of SNI will probably not support IPv6

Quick solution might be 1, but that could be overwritten by ispconfig resyncs. Apache processes the contents of config sub-directories in alpha-numeric sort order. So renaming your main site in the sites-enabled folder to something like "000-.." such that it is the first in alpha-numeric ordering will make it the default page. I don't know if you can do that in a way that ISPC is not overwriting that change, though..

 

@Th0m I double checked the Domains. No Domain with an asteriks. Every domain use THE correct IPv4 and IPv6 Address.

 

@Jesse Norell @Steini86 Thanks for your explanations!

You're right. 1. and 2. are no options. I will go with 3. as this seems to be the best option for this small customer group.

Thanks a lot for your help!
Greetings!

 

I have a wild guess about ipv6 that may cause your problem, so if I were you, I will test disabling ipv6 and see how it goes. I personally always have problems with ipv6 and still haven't found the right way to use it smoothly on my servers.

 

I would advise against turning off IPv6 in 2020. Depending on your region and customers you will cut them off. Here, there is only IPv6 for mobile users and they will all be excluded then.

 

On the contrary actually, I do believe I said "test disabling ipv6" and to me it will allow you to determine if you have any problems with it.

While running test by disabling ipv6, I don't think it will cut you from anyone at all, provided your ipv4 is already properly set and working.

Anyway, as said, it is just a wild guess and you can simply ignore doing such a test.