9

The SSL certificate on menswearireland.com and on www.menswearireland.com works fine on Safari, Chrome, SeaMonkey, K-Meleon, QtWeb, Firefox, and Opera. However, Internet Explorer claims that there is an error:

The security certificate presented by this website was not issued by a trusted certificate authority. The security certificate presented by this website was issued for a different website's address.

Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)

Another site hosted on the same managed server shows no errors: achill-fieldschool.com and www.achill-fieldschool.com work fine on IE, even though as far as I can tell the certificate is set up identically.

What am I doing wrong?

This is a LAMPP server running Plesk.

It looks like the server is showing different certificates to different clients. To some clients it shows a RapidSSL certificate made out to www.menswearireland.com with menswearireland.com as a valid alternative name. To other clients, it shows a Parallels Panel certificate, made out to Parallels Panel. Here are results from a few different online SSL checkers: most say it's fine, while two show errors.

Three online checkers say it's valid

Comodo SSL Check shows it as valid

Comodo SSL Check shows it as valid

DigiCert SSL Check shows it as valid

DigiCert SSL Check shows it as valid

SSL Shopper SSL Check shows it as valid

SSL Shopper SSL Check shows it as valid

Common name: www.menswearireland.com
SANs: www.menswearireland.com, menswearireland.com
Valid from October 2, 2012 to November 4, 2013
Serial Number: 559425 (0x88941)
Signature Algorithm: sha1WithRSAEncryption
Issuer: RapidSSL CA

Another online checker seems to see a completely different certificate

GeoCerts SSL Check shows it as invalid

GeoCerts SSL Check shows it as invalid

Common name: Parallels Panel
Organization: Parallels
Valid from August 15, 2012 to August 15, 2013
Issuer: Parallels Panel

Another online checker sees more than one certificate

Symantic SSL Check shows it as invalid

Symantic SSL Check shows it as invalid

The certificate installation checker connected to the Web server and read its certificates, but could not determine which is the primary certificate for the Web server.

Incidentally, on both menswearireland.com and achill-fieldschool.com the homepage will redirect from HTTPS to HTTP. To see SSL details, visit the page /account on both (that page will redirect from HTTP to HTTPS).

I’ve found more information in a more detailed online SSL checker.

https://www.ssllabs.com/ssltest/analyze.html?d=menswearireland.com

This site works only in browsers with SNI support

My understanding is that SNI (RFC 6066) is a method for putting many SSL sites on one shared IP address and port. This does not work on Internet Explorer on older versions of Windows (this has to do with the version of Windows, not the version of Internet Explorer). However, all our SSL sites are on a unique IP address, so we shouldn’t need SNI.

Chris S
  • 77,945
  • 11
  • 124
  • 216
TRiG
  • 1,181
  • 3
  • 13
  • 30
  • I'd guess you are using Parallels? Sounds like the Parallels Panel self-signed cert installed is interfering with that domain, possibly installed on the same IP? – TheCleaner Nov 19 '12 at 16:47

3 Answers3

8

So it turns out that in Plesk 11.0 it isn't enough to assign an SSL cert with a website on a dedicated IP address. You also have to go to the list of IP addresses (Server Management > Tools and Settings > Tools & Resources > IP Addresses) and set the "Default site" for each IP address to be the site on that address.

If you don't do that, Plesk serves the cert in a manner which requires SNI, which rather obviates the benefits of putting each secured site on a dedicated IP address in the first place.

You can also set the SSL cert there, but that is unnecessary. This seems to be more confusing than necessary.

TRiG
  • 1,181
  • 3
  • 13
  • 30
4

When I accessed the website https://www.menswearireland.com from my company LAN (firewall proxy and all) I got an SSL error:

VERIFY DENY: depth=0, (18) self signed certificate: "Parallels Panel"
VERIFY DENY: depth=0, CommonName "Parallels Panel" does not match         
URL "www.menswearireland.com"

This would mean that the certificate is apparently a self-signed certificate and that's a big NO GO for Internet Explorer.

John K. N.
  • 2,055
  • 1
  • 17
  • 28
  • There's a RapidSSL cert on that, working fine on all other browsers, and showing up on the SSL Checker. So why on Earth is a different cert being served to IE and to you? – TRiG Nov 16 '12 at 12:43
  • I've updated the question with some extra information. I'm very confused now. – TRiG Nov 16 '12 at 13:12
  • @TRiG I would be too. So both sites are hosted on the same LAMP instance? Or are these two different physical/virtual servers? – John K. N. Nov 16 '12 at 13:35
  • @TRiG I get two different IP addresses for the two domains, but that could be that your LAMP server picks up the call on both IP addresses. – John K. N. Nov 16 '12 at 13:38
  • @TRiG When I accessed the newly mentioned site www.achill-fieldschool.com via HTTPS / SSL, I didn't get a response at all. The website was displayed without HTTPS/SSL. – John K. N. Nov 16 '12 at 14:42
  • Yes, the HTTPS page redirects to a HTTP page (because there is some embedded mixed content on some pages, and we don't want warnings). The fact that you got as far as seeing the redirect means that the SSL stuff happened safely. If you want to see the SSL details, visit `achill-fieldschool.com/account`, which redirects *to* HTTPS. – TRiG Nov 16 '12 at 15:01
3

I know that this is an old thread, but it helped me solve a similar issue. I determined it to be IPv6 related as opposed to SNI. It turns out that Verizon Wireless and other ISPs are increasingly using IPv6 instead of IPv4. It was a frustrating issue because the only commonality that I could come up with was that the majority of my customers that were having the issue were using Verizon, but not all Verizon LTE connections use IPv6 so some worked correctly. In my case, I needed to assign the certificate to the IPv6 address on my Plesk Server as well as the IPv4 address and the problem was solved.

Stoli
  • 31
  • 1