CertPathValidatorException with Windows server and Android client

Question

I installed a new PositiveSSL certificate from Comodo on a Windows Server 2008 R2 computer. I successfully connected from the following clients

• Chrome for Windows
• Chrome for Android
• Firefox for Windows
• Internet Explorer
• Vivaldi for Windows
• Opera for Windows (both HTTPS and IMAP)
• Remote Desktop Connection for Windows

to the following servers

• Apache with mod_ssl
• Remote Desktop Services
• MDaemon

However, when I use K-9 Mail for Android to connect to MDaemon, I get the error

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

I assume that Chrome and K-9 behave differently on the same phone because Chrome for Android ships its own Root CA store and doesn't rely on the Android OS Root CA store, or at least has different trust validation logic.

The certificates I installed came directly from the ZIP file that Comodo emailed to me:

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) 

When I installed these into the Windows Certificate Store for RDP and MDaemon to use, I converted these certs into a PKCS12 file using

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 

and then imported the PFX file into the Certificates MMC Snap-In for the Computer Account using the automatic store destination. I selected the new cert in MDaemon's Security Settings dialog under SSL & TLS > MDaemon and hit Restart Servers. Using OpenSSL, I can see that the correct certificate is being served along with intermediate certs.

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

I looked at the certificate chain in Android and whether the root CA was in Android's CA store.

Here is the expected full certificate chain. The names below are Common Names (CN).

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

I saw that the AddTrust External CA Root did exist in the Android certificate store with the correct thumbprint.

Why is K-9 Mail throwing the error stating that there is no path from my server's TLS certificate to a trusted root CA?

Answer 1

The answer came from a Comodo knowledge base article: Untrusted Certificate Error on Android.

The cause of the error is the existing Comodo certificates in the default Windows certificate store. One of the intermediate certificates, the COMODO RSA Certification Authority, is present by default in the Trusted Root Certification Authorities folder as a self-issued CA cert. I didn't install it there, Windows has it in a stock installation. I'm not sure why it's there, because the real COMODO RSA Certification Authority is issued by AddTrust, not itself, and the thumbprints don't match. Additionally, this bogus self-issued Comodo Root CA is not present in Android 4.4's root store, even though there are three other Comodo CAs with CNs similar enough to be confusing unless you check the thumbprints. Maybe there is some historical reason related to CA reorganization between Comodo and AddTrust.

The solution from the KB article has fixed the error in K-9: remove the self-issued COMODO RSA Certification Authority from the Windows Trusted Root Certification Authorities (I actually cut and pasted it to a different folder in case I needed to revert the change, instead of permanently deleting it).

This bogus cert caused MDaemon to assume that the higher-level intermediate Comodo cert was actually a root cert, and it didn't send it in the SSL handshake to K-9. This was indicated but not made obvious enough to me in the s_client output. Before the fix, MDaemon was only sending the bottom two certificates in the chain, and Android did not have a trust path from the third certificate (Comodo Domain Validation) to AddTrust, because the second certificate was missing in the response. After the fix, MDaemon sent the bottom three certificates in the chain, and Android was able to successfully find a path from Comodo Certification CA to AddTrust.

One unresolved item is the Windows automatic root CA updates. Comodo warns that these updates will restore the unwanted cert to the Trusted Root CA store, and recommends that you disable all root CA updates. I think this is not the best solution because I want the root CA list to stay up to date with this one exception. I'm considering trying to find or write a program that can delete a given certificate from the computer certificate store and have that run periodically. Maybe there's a PowerShell or certmgr.exe based script I can write. At the very least, maybe I can add some automated monitoring when the root CA list is updated and the unwanted certificate is restored, so I know it's time to delete it manually.