O Firefox não carrega cadeia de certificados

6

Estou executando lighttpd/1.4.28 (ssl) no Debian Squeeze. Acabei de criar um certificado de link , eu corro bem em todos os meus navegadores (Firefox, Chrome, Opera), mas meus usuários estão relatando erros de certificado em Raposa de fogo. Eu já acertei a falha do carregamento da cadeia de certificados:

Certificado no meu Firefox: link
Certificado em outros Firefox: link (Observe os certificados StartCOM em falta aqui)

Eu segui este tutorial para incorporar o certificado no meu lighttpd: link

As partes relevantes do meu lighttpd.conf são assim:

$SERVER["socket"] == ":443" {
        ssl.engine = "enable"
        ssl.ca-file = "/etc/lighttpd/certs/ca-bundle.pem"
        ssl.pemfile = "/etc/lighttpd/certs/www.bisaboard.crt"
}

O ca-bundle.pem foi criado assim: cat ca.pem sub.class1.server.ca.pem > ca-bundle.pem
Eu peguei os arquivos relevantes aqui: link

www.bisaboard.crt foi criado assim: cat certificate.pem ssl.key > www.bisaboard.crt
Onde certificate.pem é meu certificado StartSSL-Class1 e ssl.key my SSL-Root-Key.

Você tem alguma idéia de por que o segundo Firefox não carrega corretamente a cadeia de certificados?

    
por TimWolla 03.01.2012 / 22:16

5 respostas

3

Seu servidor não parece apresentar os certificados intermediários corretamente, o motivo pelo qual ele funciona em seu próprio navegador é provavelmente porque você fez o download e os instalou localmente.

Por que você não faz o download do pacote ca que eles já prepararam para você no link e usa que para a opção ssl.ca-file ?

    
por 03.01.2012 / 22:40
1

O Firefox é notoriamente rigoroso ao obter toda a cadeia de certificados verificada, e é provável que você não tenha especificado todos os certificados na cadeia corretamente. Recentemente, tive um problema semelhante com o Firefox e um certificado Comodo SSL no Lighttpd, e o problema era que eu não listei a cadeia no arquivo ssl.ca corretamente.

De acordo com a RFC 2246 , o certificado do remetente deve vir primeiro e cada certificado seguinte deve certificar diretamente o que o precede. Acabei tendo quatro certificados na cadeia até o CA Root.

certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

    
por 02.06.2014 / 10:45
0

Eu tive um problema com comportamento exatamente similar: alguns Firefox estavam reclamando sobre falta de cadeia, mas não todos. Adicionando um parâmetro de cadeia de certificado adicional (e arquivo que continha todos os certificados um após o outro) para a configuração do servidor parecia ajudar. Estou executando o Apache Traffic Server sozinho.

Essa solução também é o que SSLhopper sugere no link nos comentários: link

Eu não sei sobre lighttpd config, mas provavelmente há um parâmetro extra para anunciar o arquivo em cadeia para os certificados intermediários.

    
por 29.01.2013 / 14:48
0

Eu tive esse mesmo problema (usando node.js) e a solução foi anexar o arquivo sub.class1.server.ca.pem ao arquivo ssl.crt .

Copie o conteúdo de sub.class1.server.ca.pem para ssl.crt , certificando-se de que um está abaixo do outro, sem espaço entre eles, e isso deve funcionar.

Você pode ler mais sobre isso aqui .

    
por 15.04.2013 / 19:31
0

Eu corri nessa questão depois de uma renovação de certificado ontem. Todos os meus dispositivos / navegadores de teste funcionaram bem com o certificado renovado, então voltei para casa.

Hoje cheguei ao escritório e metade de nossa empresa / clientes viu esse aviso de segurança do navegador em seus navegadores.

Mesmo com a mesma versão de ESR do Firefox implantada aqui na empresa?!

Minha solução foi usar o certificado intermediário válido correto no servidor.

Esqueci totalmente os problemas do SHA1 que o StartCom tem de forma ativa.

Obtenha o certificado intermediário SHA2 válido no domínio da classe 1 atual (no meu caso): link , substitua o velho onesub.class1.server.ca.pem com ele, reinicie o servidor web (Apache no meu final) e ele funcionará em todos os navegadores.

    
por 14.10.2016 / 13:18