eu tenho umempresa.svdomínio e comprei recentemente um certificado curinga RapidSSL, instalei-o e testei-o com vários navegadores (Firefox, Chromium, Chrome, IE) e ferramentas de verificação SSL, funcionou bem em todos, exceto no Google Chrome, nem no Windows, Linux e Android.
Toda vez que acesso o site pelo Google Chrome aparece um aviso dizendo que tentei acessarwww.empresa.svoutanto faz.empresa.svmas o servidor se identifica como **.company.sv*. Se eu continuar apesar do aviso e clicar no cadeado vermelho, isso indica que estou conectado a um servidor que só é válido dentro da minha rede e não pode ser validado por uma entidade de certificação externa.
Entrei em contato com o serviço de suporte do revendedor de certificados, mas eles não conseguiram me dar uma resposta direta sobre qual era o problema. Fiquei me perguntando se isso tem algo a ver com o TLD ser.sv. Também verifiquei o código-fonte do Chromium, mas parece meio inútil, já que o certificado funciona perfeitamente no Chromium.
Talvez valha a pena mencionar que estou usando o NGINX em um servidor Ubuntu 12.04 e que testei um certificado de domínio único gratuito da Comodo antes de comprar o curinga.
Responder1
Parece que você esqueceu de instalar o pacote de certificados intermediários em seu servidor web. Visite o site do fornecedor do certificado para baixar o pacote intermediário.
Para nginx, isso deve ser concatenado com seu certificado e colocado na ssl_certificatediretiva, por exemplo:
# cat company.sv.crt ca_bundle.crt > company.sv.chained.crt
E na sua configuração do nginx:
ssl_certificate /etc/path/to/company.sv.chained.crt
Responder2
Suspeito que você tenha o nome do site no campo Assunto CN=. Ele precisa estar no campo de nome alternativo do assunto para que o Chrome o aceite. se você exibir o certificado no navegador ou comopenssl x509 -in certificate-file -text
Ver:
Esses requisitos básicos determinam que as autoridades de certificação sempre incluam pelo menos um Nome Alternativo do Assunto nos certificados SSL que emitem, isso significa que hoje um aplicativo não precisa procurar tanto o Nome Comum quanto o Nome Alternativo do Assunto, eles só precisam verificar o último.
Atualmente, a maioria das Autoridades de Certificação também incluirá o primeiro Nome DNS do Nome Alternativo do Assunto no campo Nome Comum, mas isso é feito principalmente por motivos legados e em algum momento em um futuro não tão distante irá parar.
Os certificados têm duas maneiras de expressar o domínio/IP ao qual estão vinculados: uma não estruturada e ambígua (commonName) e outra bem definida (subjectAltName). Na ausência de qualquer subjectAltNames, o Chrome atualmente compara o domínio com o commonName, se presente.
Esta proposta visa remover esse caminho alternativo; na verdade, exigindo um subjectAltName. Idealmente, faríamos isso para todos os certificados (de confiança pública e de confiança privada), mas se houver preocupações sobre o risco de compatibilidade, podemos restringi-lo a certificados de confiança pública.