CertPathValidatorException avec serveur. Windows et client Android

J'ai installé un nouveau certificat PositiveSSL de Comodo sur l'ordinateur S. Windows Server 2008 R2. J'ai connecté avec succès des clients suivants

Chrome pour Windows

Chrome pour Android

Firefox pour Windows

Internet Explorer

Vivaldi pour Windows

Opera pour Windows (comme HTTPS, donc je. IMAP)

Connectez-vous à un bureau distant pour Windows

sur les serveurs suivants

Apache de mod_ssl

Services de bureau à distance

MDaemon

Cependant, quand j'utilise K-9 Mail pour Android Connecter K. MDaemon, Je reçois un message d'erreur

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

je suppose que Chrome et K-9 se comporter différemment sur le même téléphone parce que Chrome pour Android a son propre référentiel de centres de certification racine et ne s'appuie pas sur les centres racines de la certification OS Android Ou au moins a une logique différente de vérification de confiance.

J'ai installé des certificats directement à partir du fichier zip, qui Comodo envoyé moi un email:

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)

Quand je les ai installés dans le magasin de certificats Windows pour utilisation RDP et MDaemon, J'ai transformé ces certificats dans le fichier PKCS12, Utilisant

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

puis importé le fichier PFX en équipement MMC Certificates Pour un compte d'ordinateur à l'aide d'une destination automatique. J'ai choisi un nouveau certificat dans la boîte de dialogue Paramètres de sécurité MDaemon» dans la section «SSL et TLS»> «MDaemon» Et cliqué sur "Serveurs de rechargement". Utilisant OpenSSL, Je vois que le certificat correct est servi avec des certificats intermédiaires.

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)
---

J'ai regardé la chaîne de certificats dans Android Et sur si l'autorité de certification root est dans la boutique ca Android.

Voici la chaîne complète attendue de certificats. Les noms suivants sont des noms communs. (CN).

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

J'ai vu la racine externe CA AddTrust existe vraiment dans le magasin de certificats Android Avec la bonne impression.

Pourquoi K-9 Mail donne une erreur qu'il n'y a pas de chemin du certificat TLS Mon serveur à la racine de confiance CA?
Invité:

Emilie

Confirmation de:

La réponse provenait des articles de la base de connaissances Comodo:
https://support.comodo.com/ind ... droid
.

Cause d'erreur - Certificats existants Comodo Dans le stockage de certificat Windows défaut. Un des certificats intermédiaires

COMODO RSA Certification Authority

, La valeur par défaut est présente dans le dossier Trusted Root Certification Authorities comme certificat CA, délivré de manière indépendante. Il n'était pas installé, sous Windows, il y a en stock Installation. Je ne sais pas pourquoi il est là parce que cette autorité de certification COMODO RSA Publié AddTrust, Et pas seul, et les empreintes digitales ne coïncident pas. De plus, ce faux auto-fabriqué Comodo Root CA Aucun dans le stockage racine Android 4.4, Bien qu'il y ait trois autres Comodo CA de CN, Quelqu'un est assez similaire à induire en erreur, si vous ne vérifiez pas les empreintes digitales. Peut-être y a-t-il une raison historique liée à la réorganisation CA compris entre Comodo et AddTrust.

La décision de l'article de la base de connaissances a corrigé l'erreur dans K-9: Supprimer votre propre autorité de certification COMODO RSA De la certification de centres de racines de confiance Windows (En fait, je l'ai coupé et mis dans un autre dossier au cas où je devrais annuler le changement , Au lieu de le retirer pour toujours).

Ce faux certificat forcé MDaemon Supposons que le certificat intermédiaire Comodo Le niveau supérieur était en réalité un certificat racine, et il ne l'a pas envoyé en reconnaissance SSL sur K-9. Il a été indiqué, mais pas évident pour moi dans la conclusion s_client. Avant la correction MDaemon envoyé seulement deux certificats inférieurs dans la chaîne et Android Il n'y avait aucun moyen de confiance du troisième certificat (Chèque de domaine Comodo) avant que AddTrust, Puisque le deuxième certificat était absent dans la réponse. Après correction MDaemon envoyé trois certificats inférieurs dans la chaîne et Android Je pourrais trouver avec succès un moyen de Comodo Certification CA à AddTrust.

Une question non résolue - Ce sont des mises à jour automatiques de l'autorité de certification racine. Windows. Comodo Il avertit que ces mises à jour restaureront un certificat indésirable dans le référentiel de CA de racine de confiance et recommande que toutes les mises à jour de la ca. Je pense que ce n'est pas la meilleure solution, car je souhaite que la liste des centres de racine de certification est restée pertinente à une exception près. Je pense à essayer de trouver ou d'écrire un programme capable de supprimer ce certificat du stockage de certificats d'ordinateur et de commencer périodiquement. Peut-être que je peux écrire un script basé sur PowerShell ou certmgr.exe. Au moins peut-être que je peux ajouter une surveillance automatique lorsque la liste de la CA root est mise à jour et que le certificat indésirable est restauré, je sais donc qu'il est temps de le supprimer manuellement.

Pour répondre aux questions, connectez-vous ou registre