O certificado de CA Raiz SSL não é reconhecido, embora esteja presente no armazenamento confiável. Por quê?

Question

Antecedentes:

• Ubuntu Server 14.10 64 bits em aws.amazon.com/ec2
• Certificado de servidor PositiveSSL barato da COMODO
• 1 certificado de servidor, 2 certificados de CA intermediários e 1 certificado de CA raiz como arquivo ZIP de COMODO
• WebCit da Citadel, httpsd

Problema:

A cadeia de certificados concatenados parece estar correta, mas a verificação falha.

openssl s_client myhost:port

mostra a cadeia de certificados e os pares emissor / assunto se alinham corretamente pela cadeia, mas:

verify error:num=19:self signed certificate in certificate chain

O certificado da CA raiz não é aceito pelo openssl, embora seja encontrado por padrão no armazenamento confiável do servidor Ubuntu.

Especificamente: AddTrustExternalCARoot.crt recebido por email da COMODO e /etc/ssl/certs/AddTrust_External_Root.pem com links para %código% são indentical.

O que está errado aqui?

    

Answer 1

O OpenSSL pelo menos até a versão atual (1.0.2a) tem um bug em que s_client com NO -CA{path,file} argumento não usa o armazenamento de confiança padrão deve, e assim falha ao verificar certificados que são válidos de acordo com esse armazenamento confiável. (Também s_server e s_time , mas se preocupando com a verificação naqueles é raro.) Veja link . Uma correção é anunciada no dev, mas pode levar algum tempo para ser liberada e distribuída. Enquanto isso, você precisa especificar explicitamente o -CA* argumento (s). Observe que openssl verify não possui esse bug e, portanto, relatou corretamente o certificado / cadeia como válido.

ATUALIZAÇÕES 2015/08/26: correção foi lançada 2015/06/12 em 1.0.1o e 1.0.2c. Além disso, enquanto investigava outra coisa, descobri que os pacotes RedHat podem ter sido bons . Mais especificamente, o RPM de origem do CentOS para openssl-1.0.1e-30.el6.11 que eu entendo é uma cópia do RedHat (mas não pode confirmar facilmente) contém openssl-1.0.1c-default-paths.patch que contém alterações para s_client.c s_server.c s_time.c de 2012/12/06 que parecem equivalentes a ( embora não seja textualmente o mesmo que) as correções upstream de 2015/06/12. Assumindo que esse patch foi aplicado nos pacotes RedHat e CentOS, que não posso facilmente voltar e verificar, eles (teriam) funcionado (ed) como esperado.

    

Answer 2

Eu enfrentei um problema parecido com certificados Comodo recentemente ao desenvolver um script usando Ruby. No final, foi que o OpenSSL não o possuía na loja, embora parecesse que sim.

Para testar isso, baixe todos os certificados intermediários Comodo e crie um pacote de certificados como este (você precisará usar nomes de certificados diferentes dependendo do que você baixou):

cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundle

Comodo tem um artigo sobre como faça isso.

Uma vez feito, tente verificar o certificado novamente usando o OpenSSL e especificando o armazenamento de certificados na linha de comando:

openssl verify -untrusted yourDomain.ca-bundle cert.pem

Esse exemplo foi adaptado de este Unix e o artigo sobre o StackExchange do Linux .

Uma vez que você determinou qual certificado é, deve ser possível adicionar o certificado à loja cert local, que é detalhado aqui para o Ubuntu , e é algo como:

Crie um diretório para certificados de CA extras em / usr / share / ca-certificates

sudo mkdir /usr/share/ca-certificates/extra

Copie o arquivo '.crt' para o diretório

sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt

Deixe o Ubuntu adicionar o caminho do arquivo '.crt' em relação a / usr / share / ca-certificates para /etc/ca-certificates.conf

sudo dpkg-reconfigure ca-certificates

    

Answer 3

O certificado raiz comodo não é mais confiável - google por "comodo stolen certificate" se você não sabe o porquê.

Embora um certificado de comodo possa ser barato, seu valor é muito menor que seu preço: ele é, na verdade, inútil, a cadeia de confiança é quebrada.