Fundo:
- Ubuntu Server 14.10 de 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 do COMODO
- WebCit da Cidadela httpsd
Problema:
A cadeia de certificados concatenada parece estar correta, mas a verificação falha.
openssl s_client myhost:port
mostra a cadeia de certificados e os pares emissor-assunto alinhados corretamente na cadeia, mas:
verify error:num=19:self signed certificate in certificate chain
O certificado CA raiz não é aceito pelo openssl, embora seja encontrado por padrão no armazenamento confiável do servidor Ubuntu.
Especificamente:
AddTrustExternalCARoot.crtrecebido por email da COMODO e
/etc/ssl/certs/AddTrust_External_Root.pemcujos links
/usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt
são idênticos.
O que há de errado aqui?
Responder1
OpenSSL pelo menos até o atual (1.0.2a) tem umerroonde s_clientsem -CA{path,file}argumentona verdade, não usa o armazenamento confiável padrãocomo deveria e, portanto, não consegue verificar os certificados válidos de acordo com esse armazenamento confiável. (Também s_servere s_time, mas preocupar-se com a verificação nesses casos é raro.) Consultehttps://serverfault.com/questions/607233/how-to-make-openssl-s-client-using-default-ca. Uma correção foi anunciada no dev, mas pode levar algum tempo para ser lançada e distribuída. Enquanto isso, você precisa especificar explicitamente o -CA*(s) argumento(s). Observe que openssl verifynão possui esse bug e, portanto, relatou corretamente o certificado/cadeia como válido.
ATUALIZAÇÕES26/08/2015:a correção foi lançada12/06/2015 em 1.0.1o e 1.0.2c. Além disso, ao investigar outra coisa, descobri quePacotes RedHat podem ter funcionado bem. Mais especificamente, o RPM de origem do CentOS para openssl-1.0.1e-30.el6.11o qual eu entendo ser uma cópia do RedHat (mas não posso confirmar facilmente) contém openssl-1.0.1c-default-paths.patchalterações s_client.c s_server.c s_time.cdatadas de 06/12/2012 que parecem equivalentes (embora não textualmente iguais) ao 2015 /06/12 correções upstream. Supondo que esse patch tenha sido aplicado em pacotes RedHat e CentOS, que não posso voltar e verificar facilmente, eles funcionariam (editados) conforme esperado.
Responder2
Enfrentei recentemente um problema semelhante com certificados Comodo ao desenvolver um script usando Ruby. No final das contas, o OpenSSL não o tinha na loja, embora parecesse que sim.
Para testar isso, baixe todos os certificados intermediários do Comodo e crie um pacote de certificados parecido com 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 fazer isso.
Uma vez feito isso, tente verificar o certificado novamente usando OpenSSL e especificando o armazenamento de certificados na linha de comando:
openssl verify -untrusted yourDomain.ca-bundle cert.pem
Esse exemplo foi adaptado deeste artigo Unix e Linux StackExchange.
Depois de determinar qual certificado é, será possível adicionar o certificado ao armazenamento de certificados local,que é detalhado aqui para Ubuntu, e é algo como:
Crie um diretório para certificados extras de CA 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' relativo a /usr/share/ca-certificates para /etc/ca-certificates.conf
sudo dpkg-reconfigure ca-certificates
Responder3
O certificado raiz comodo não é mais confiável - pesquise no Google por "certificado roubado comodo" se você não sabe por quê.
Embora um certificado comodo possa ser barato, o seu valor é muito inferior ao seu preço: na verdade, não tem valor e a cadeia de confiança está quebrada.