1

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?

1 Answer 1

2

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.

2
  • The Windows Trusted Root CA list got updated today and K-9 Mail started throwing SSL errors again. I manually deleted the COMODO RSA Certification Authority from the Trusted Root Certificate Authorities list again.
    – Aldaviva
    Jun 6, 2017 at 1:33
  • I installed the Windows 10 SDK and got certmgr.exe from C:\Program Files (x86)\Windows Kits\10\bin\x86. I have added a task to the Task Scheduler that periodically runs certmgr.exe -del -c -sha1 afe5d244a8d1194230ff479fe2f897bbcd7a8cb4 -s -r localMachine Root. You can also use -n "COMODO RSA Certification Authority" in place of the -sha1 afe... argument if you prefer.
    – Aldaviva
    Jun 18, 2017 at 6:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .