O certificado SSL em menswearireland.come sobre www.menswearireland.comfunciona bem no Safari, Chrome, SeaMonkey, K-Meleon, QtWeb, Firefox e Opera. No entanto, o Internet Explorer afirma que há um erro:

O certificado de segurança apresentado por este site não foi emitido por uma autoridade de certificação confiável. O certificado de segurança apresentado por este site foi emitido para um endereço de site diferente.

Problemas no certificado de segurança podem indicar uma tentativa de enganar ou interceptar quaisquer dados enviados ao servidor.

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

Outro site hospedado no mesmo servidor gerenciado não mostra erros: achill-fieldschool.come www.achill-fieldschool.comfunciona bem no IE, mesmo que eu saiba que o certificado está configurado de forma idêntica.

O que estou fazendo errado?

Este é um servidor LAMPP executando o Plesk.

Parece que o servidor está mostrando certificados diferentes para clientes diferentes. Para alguns clientes, ele mostra um certificado RapidSSL www.menswearireland.comcom menswearireland.comum nome alternativo válido. Para outros clientes, ele mostra um certificado do Parallels Panel, feito para Parallels Panel. Aqui estão os resultados de alguns verificadores SSL online diferentes: a maioria diz que está tudo bem, enquanto dois mostram erros.

Três verificadores online dizem que é válido

Comodo SSL Check mostra como válido

O DigiCert SSL Check mostra-o como válido

SSL Shopper SSL Check mostra como válido

Nome comum: www.menswearireland.com
SANs: www.menswearireland.com, menswearireland.com
Válido de 2 de outubro de 2012 a 4 de novembro de 2013
Número de série: 559425 (0x88941)
Algoritmo de assinatura: sha1WithRSAEmissor de criptografia
: RapidSSL CA

Outro verificador on-line parece ver um certificado completamente diferente

A verificação SSL do GeoCerts mostra como inválida

Nome comum: Parallels Panel
Organização: Parallels
Válido de 15 de agosto de 2012 a 15 de agosto de 2013
Emissor: Parallels Panel

Outro verificador on-line vê mais de um certificado

Symantic SSL Check mostra-o como inválido

O verificador de instalação do certificado se conectou ao servidor da Web e leu seus certificados, mas não conseguiu determinar qual é o certificado principal do servidor da Web.

Aliás, em ambos menswearireland.come achill-fieldschool.coma página inicial será redirecionada de HTTPS para HTTP. Para ver os detalhes do SSL, visite a página /accountem ambos (essa página será redirecionada de HTTP para HTTPS).

Encontrei mais informações em um verificador SSL online mais detalhado.

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

Este site funciona apenas em navegadores com suporte SNI

Meu entendimento é que o SNI (RFC 6066) é um método para colocar muitos sites SSL em um endereço IP e porta compartilhados. Isso não funciona no Internet Explorer em versões mais antigas do Windows (isso tem a ver com a versão do Windows, não com a versão do Internet Explorer). No entanto, todos os nossos sites SSL estão em um endereço IP exclusivo, portanto, não precisamos do SNI.

Portanto, no Plesk 11.0, não é suficiente atribuir um certificado SSL a um site em um endereço IP dedicado. Você também precisa ir para a lista de endereços IP (Gerenciamento de servidor> Ferramentas e configurações> Ferramentas e recursos> Endereços IP) e definir o "Site padrão" para cada endereço IP como o site nesse endereço.

Se você não fizer isso, o Plesk atende ao certificado de uma maneira que requer o SNI, o que evita os benefícios de colocar cada site protegido em um endereço IP dedicado.

Você também pode definir o certificado SSL lá, mas isso é desnecessário. Isso parece ser mais confuso do que o necessário.

Quando acessei o site https://www.menswearireland.com na LAN da minha empresa (proxy de firewall e tudo), recebi um erro SSL:

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

Isso significa que o certificado é aparentemente um certificado autoassinado e é um grande NO GO para o Internet Explorer.

Sei que esse é um tópico antigo, mas me ajudou a resolver um problema semelhante. Eu determinei que era relacionado ao IPv6, em vez do SNI. Acontece que a Verizon Wireless e outros ISPs estão cada vez mais usando o IPv6 em vez do IPv4. Foi um problema frustrante, porque o único ponto em comum que eu pude descobrir foi que a maioria dos meus clientes que estavam tendo o problema estava usando a Verizon, mas nem todas as conexões Verizon LTE usam IPv6, portanto, algumas funcionaram corretamente. No meu caso, eu precisei atribuir o certificado ao endereço IPv6 no meu Plesk Server, bem como ao endereço IPv4, e o problema foi resolvido.