CertPathValidatorException com servidor Windows e cliente Android

1

Instalei um novo certificado PositiveSSL do Comodo em um computador com Windows Server 2008 R2. Eu me conectei com sucesso a partir dos seguintes clientes

  • Chrome for Windows
  • Chrome para Android
  • Firefox para Windows
  • Internet Explorer
  • Vivaldi para Windows
  • Opera para Windows (HTTPS e IMAP)
  • Conexão de área de trabalho remota para Windows

para os seguintes servidores

  • Apache com mod_ssl
  • Serviços de área de trabalho remota
  • MDaemon

No entanto, quando eu uso o K-9 Mail para Android para conectar ao MDaemon, recebo o erro

java.security.cert.CertPathValidatorException: Trust Anchor for certificate path not found

Suponho que o Chrome e o K-9 se comportam de maneira diferente no mesmo telefone, porque o Chrome para Android envia seu próprio armazenamento de CA e não depende do armazenamento da CA raiz do Android ou pelo menos tem uma lógica de validação de confiança diferente. / p>

Os certificados que eu instalei vieram diretamente do arquivo ZIP que o Comodo enviou para mim:

AddTrustExternalCARoot.crt (this is the root CA)
COMODORSAAddTrustCA.crt (this is a higher-level intermediate CA)
COMODORSADomainValidationSecureServerCA.crt (this is a lower-level intermediate CA)
www_myserver_com.crt (this is my server's cert)

Quando os instalei no Armazenamento de certificados do Windows para uso do RDP e do MDaemon, converti esses certificados em um arquivo PKCS12 usando

cat "./www_myserver_com.crt" "./COMODORSADomainValidationSecureServerCA.crt" "./COMODORSAAddTrustCA.crt" "AddTrustExternalCARoot.crt" > "./fullchain.crt"
openssl pkcs12 -in "./fullchain.crt" -inkey "./www_myserver_com.key" -out "./fullchain.pfx" -export

e, em seguida, importou o arquivo PFX para o snap-in de certificados do MMC para a conta de computador usando o destino de armazenamento automático. Selecionei o novo certificado na caixa de diálogo Configurações de segurança do MDaemon, em SSL & TLS > MDaemon e clique em Reiniciar Servidores. Usando o OpenSSL, posso ver que o certificado correto está sendo exibido junto com certificados intermediários.

C:\>openssl s_client -connect myserver.com:993
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN
= COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN
= COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.myserver.com
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.myserver.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Dom
ain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Dom
ain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Cer
tification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MII..8hg==
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=www.myserver.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA D
omain Validation Secure Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3401 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: F04A0000068E4DC91357783440DA44EEB39DA3C813C3C646EBCE29DDD3E8C139

    Session-ID-ctx:
    Master-Key: FF3D72A03F1F93686AC6EAB38198036C7AF1780250ED3F510A83CE6DC166778F
A726DBC2AA4ED6C5277A0969D175E419
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1495135778
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Analisei a cadeia de certificados no Android e se a CA raiz estava no armazenamento de CA do Android.

Aqui está a cadeia de certificados completa esperada. Os nomes abaixo são nomes comuns (CN).

AddTrust External CA Root
└─COMODO RSA Certification Authority
  └─COMODO RSA Domain Validation Secure Server CA
    └─www.myserver.com

Vi que a raiz da CA externa AddTrust existia no repositório de certificados do Android com a impressão digital correta.

Por que o K-9 Mail está jogando o erro dizendo que não há caminho do certificado TLS do meu servidor para uma autoridade de certificação raiz confiável?

    
por Aldaviva 21.05.2017 / 09:07

1 resposta

2

A resposta veio de um artigo da Base de Conhecimento Comodo: Erro de certificado não confiável no Android .

A causa do erro são os certificados Comodo existentes no armazenamento de certificados padrão do Windows. Um dos certificados intermediários, o COMODO RSA Certification Authority , está presente por padrão na pasta Autoridades de Certificação Raiz Confiáveis como um certificado de CA de auto-emissão. Eu não instalei lá, o Windows tem em uma instalação de estoque. Não sei por que está lá, porque a verdadeira Autoridade de Certificação RSA da COMODO é emitida pela AddTrust, não por ela mesma, e as impressões digitais não combinam. Além disso, este falso auto-emitido Comodo Root CA não está presente no armazenamento de raiz do Android 4.4, embora existam três outras Comodo CAs com CNs similares o suficiente para serem confusas, a menos que você verifique as impressões digitais. Talvez haja algum motivo histórico relacionado à reorganização de CA entre Comodo e AddTrust.

A solução do artigo da KB corrigiu o erro em K-9: remova a Autoridade de Certificação COMODO RSA auto-emitida das Autoridades de Certificação Raiz Confiáveis do Windows (na verdade, recortei e colei em uma pasta diferente no caso de precisar reverter a alteração, em vez de excluí-la permanentemente).

Esse certificado falso fez com que o MDaemon assumisse que o certificado Comodo intermediário de nível superior era na verdade um certificado raiz e não o enviou no handshake SSL para o K-9. Isso foi indicado, mas não ficou óbvio o suficiente para mim na saída s_client. Antes da correção, o MDaemon só enviava os dois certificados inferiores da cadeia, e o Android não tinha um caminho de confiança do terceiro certificado (Comodo Domain Validation) para AddTrust, porque o segundo certificado estava faltando na resposta. Após a correção, o MDaemon enviou os três certificados inferiores da cadeia, e o Android conseguiu encontrar um caminho da Comodo Certification CA para a AddTrust.

Um item não resolvido são as atualizações automáticas da CA raiz do Windows. Comodo avisa que essas atualizações irão restaurar o certificado indesejado no armazenamento da CA Raiz Confiável e recomenda que você desative todas as atualizações da CA raiz. Acho que essa não é a melhor solução porque quero que a lista de CAs raiz fique atualizada com essa única exceção. Eu estou pensando em tentar encontrar ou escrever um programa que pode excluir um determinado certificado do armazenamento de certificados do computador e ter que executar periodicamente. Talvez haja um script baseado em PowerShell ou certmgr.exe que eu possa escrever. No mínimo, talvez eu possa adicionar algum monitoramento automatizado quando a lista da CA raiz for atualizada e o certificado indesejado for restaurado, então sei que é hora de excluí-lo manualmente.

    
por 21.05.2017 / 09:07