Por que o site está exibindo certificados SSL diferentes para diferentes navegadores? [fechadas]

Question

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

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)

Outro site hospedado no mesmo servidor gerenciado não mostra erros: achill-fieldschool.com e www.achill-fieldschool.com funcionam bem no IE, embora, até onde eu saiba, o certificado esteja configurado de forma idêntica.

O que estou fazendo de 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 criado para www.menswearireland.com com menswearireland.com como um 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 on-line diferentes: a maioria diz que está tudo bem, enquanto dois mostram erros.

Três damas on-line dizem que é válido

O Verodo SSL do Comodo mostra-o como válido

Verificação SSL DigiCert mostra como válido

O SSL SSL verifica como válido

Commonname:www.menswearireland.com
SANs:www.menswearireland.com,menswearireland.com
ValidfromOctober2,2012toNovember4,2013
SerialNumber:559425(0x88941)
SignatureAlgorithm:sha1WithRSAEncryption
Issuer:RapidSSLCA

Outroverificadoron-linepareceverumcertificadocompletamentediferente

Verificação SSL do GeoCerts mostra isso como inválido

Commonname:ParallelsPanel
Organization:Parallels
ValidfromAugust15,2012toAugust15,2013
Issuer:ParallelsPanel

Outroverificadoron-linevêmaisdeumcertificado

Verificação SSL da Symantic mostra-o como inválido

ThecertificateinstallationcheckerconnectedtotheWebserverandreaditscertificates,butcouldnotdeterminewhichistheprimarycertificatefortheWebserver.

Apropósito,emmenswearireland.comeachill-fieldschool.com,apáginainicialseráredirecionadadeHTTPSparaHTTP.ParaverdetalhesdoSSL,visiteapágina/accountemambos(essapáginaseráredirecionadadeHTTPparaHTTPS).

EncontreimaisinformaçõesemumverificadordeSSLon-linemaisdetalhado.

link

This site works only in browsers with SNI support

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 a versão do Internet Explorer). No entanto, todos os nossos sites SSL estão em um endereço IP exclusivo, por isso não precisamos do SNI.

    

Answer 1

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

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

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

    

Answer 2

Quando acessei o link do site da LAN da minha empresa (proxy de firewall e tudo), recebi um erro de 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 significaria que o certificado aparentemente é um certificado autoassinado e que é um grande NÃO IR para o Internet Explorer.

    

Answer 3

Eu sei que este é um tópico antigo, mas ajudou-me a resolver um problema semelhante. Eu determinei que fosse relacionado ao IPv6 em oposição ao SNI. Acontece que a Verizon Wireless e outros ISPs estão usando cada vez mais o IPv6 em vez do IPv4. Foi uma questão frustrante, porque a única semelhança que eu poderia encontrar era que a maioria dos meus clientes que estavam tendo o problema estavam usando a Verizon, mas nem todas as conexões Verizon LTE usam IPv6, então algumas funcionaram corretamente. No meu caso, eu precisava atribuir o certificado ao endereço IPv6 no meu servidor Plesk, bem como ao endereço IPv4, e o problema foi resolvido.