Score:1

SSL certificates apparently confusing different websites

ug flag

My VPS contains a dozen or so websites, with several SSL certificate including the following.

  • *.railtrax.com
  • *.insiderarticles.com

Currently, all the *.railtrax.com websites are working fine. But the *.insiderarticles.com website (I only have one) is giving me an error in the browser (note the last paragraph).

Your connection isn't private

Attackers might be trying to steal your information from insiderarticles.com (for example, passwords, messages, or credit cards).

NET::ERR_CERT_COMMON_NAME_INVALID

This server couldn't prove that it's insiderarticles.com; its security certificate is from *.railtrax.com. This may be caused by a misconfiguration or an attacker intercepting your connection.

As you can see, the certificate for insiderarticles.com says it was issued to *.railtrax.com.

Insiderarticles.com Certificate

insiderarticles.com certificate

But I have the correct certificate selected.

Insiderarticles.com Edit Bindings Dialog

insiderarticles.com Edit Bindings dialog

If I use Jexus to run binding diagnostics, I get the following errors:

BINDING: http 74.208.136.116:80:insiderarticles.com
Found a conflicting TCP reserved port range. Please run "netsh int ipv4 show excludedportrange protocol=tcp" at command prompt to troubleshoot.

BINDING: http 74.208.136.116:80:www.insiderarticles.com
Found a conflicting TCP reserved port range. Please run "netsh int ipv4 show excludedportrange protocol=tcp" at command prompt to troubleshoot.

BINDING: https 74.208.136.116:443:insiderarticles.com
Found a conflicting TCP reserved port range. Please run "netsh int ipv4 show excludedportrange protocol=tcp" at command prompt to troubleshoot.

BINDING: https 74.208.136.116:443:www.insiderarticles.com
Found a conflicting TCP reserved port range. Please run "netsh int ipv4 show excludedportrange protocol=tcp" at command prompt to troubleshoot.

And if I run the suggested command, I get the following.

enter image description here

But this isn't helpful to me.

Everything else about the certificates appears valid. I installed the certificate for *.insiderarticles.com and it was working fine. After I installed the certificate for *.railtrax.com, that's most likely when insiderarticles.com stopped working.

Could this have anything to do with the Require Server Name Indication checkbox? This checkbox was checked for insiderarticles.com and unchecked for all the *.railtrax.com websites. I tried checking this option for all the *.railtrax.com websites, but it didn't appear to make any difference.

Can anyone recommend next steps to troubleshoot this?

de flag
It's telling you why the name is invalid. The URL is *.insiderarticles.com, but the cert doesn't match that, and says it's intended for *.railtrax.com . Looks like the wrong cert (insiderarticles) is bound to the wrong site (railtrax), and you need to chain the railtrax cert (and intermediate) to the railtrax site. Either that, or reissue a cert with both values in Subject Alternate Name, if they are related, and chain to both.
Jonathan Wood avatar
ug flag
@Dallas: In the edit bindings dialog, I'm selecting the correct certificates from the drop down. How else could the wrong certificate be associated with the site?
Lex Li avatar
vn flag
Whatever changes you made in IIS Manager, are saved in Windows HTTP API, https://docs.jexusmanager.com/tutorials/https-binding.html#background So if something isn't right, follow the principles and check what's wrong.
Jonathan Wood avatar
ug flag
@LexLi: I installed that tool But I really don't know how it helps me. Was hoping someone who knew the basics about configurating SSL certificates could answer a couple of questions.
Lex Li avatar
vn flag
I didn't ask you to run binding diagnostics, as that's irrelevant, but pointed you to learn how Windows HTTP API matches incoming HTTPS requests to their corresponding certificates. The answer you accepted below simply says the same though fails to tell the connection to HTTP API.
Jonathan Wood avatar
ug flag
@LexLi: No, you didn't tell me to run binding diagnostics. You referred me to a tutorial, which appears to cover a great many details, and told me to follow that. It should have been clear I was looking for someone who might be able to help narrow it down. Posting a link wasn't doing that.
Score:1
us flag

Originally, you could only use a single certificate for an IP:port pair is IIS. This was because host header is not visible during SSL handshake when IIS picks the certificate to be used.

As a solution to this limitation SNI was introduced. It is available in IIS 8 and later and supported by modern browsers (list is here) . You should enable SNI for all web sites, but you might want to have it turned off for a web site which would be used by legacy browsers that do not support SNI. Those legacy browsers would still get SSL certificate name mismatch error.

So your options are one of the following:

  • if legacy browser support is not important, enable SNI for all web sites, except for the one you pick as default for legacy browsers
  • add one more public IP address to your server. Bind each certificate to different IP:port pair
  • purchase a single certificate which can cover both wildcard domains. It is called Multi-Domain Wildcard SSL Certificate or SAN Certificate
Jonathan Wood avatar
ug flag
Thanks, but both certificates are wildcard certificates (you can see the asterisk in the certificate dialog). I do have another, non-wildcard certificate on the site. But that seems to be working fine.
Jevgenij Martynenko avatar
us flag
I have updated my answer with more detailed explanation
Jonathan Wood avatar
ug flag
Thanks. Does SNI not play any role in all this then?
Jevgenij Martynenko avatar
us flag
Sorry, I completely missed this part. Updated my answer
Score:1
ug flag

I'm now thinking that the Require Server Name Indication is the issue.

I indicated I tried checking this option for all my railtrax.com websites and that this made no difference. Looking again today, it appears I missed one. After checking that one, it now seems to be working.

It's possible that something else is at play here. But so far it appears this is the answer. I'm a little surprised more people here didn't seem familiar with this.

Score:0
ms flag

I had the same issue. But in my case one of the sites only had bindings to port 80. I had to add a HTTPS binding and then select SNI.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.