web-dev-qa-db-ja.com

WindowsサーバーとAndroidクライアント）でのCertPathValidatorException

Comodoの新しいPositiveSSL証明書をWindowsServer 2008R2コンピューターにインストールしました。次のクライアントから正常に接続しました

  • Windows用Chrome
  • Chrome for Android
  • Windows用Firefox
  • インターネットエクスプローラ
  • Vivaldi for Windows
  • Opera for Windows（HTTPSとIMAPの両方）
  • Windows用のリモートデスクトップ接続

以下のサーバーへ

  • Mod_sslを使用したApache
  • リモートデスクトップサービス
  • MDaemon

ただし、K-9 Mail for Androidを使用してMDaemonに接続すると、エラーが発生します

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

ChromeとK-9は、同じ電話で異なる動作をすると思います。これは、Chrome for Androidが独自のルートCAを出荷しているためです。ストアであり、Android OSルートCAストアに依存していないか、少なくとも異なる信頼検証ロジックがあります。

私がインストールした証明書は、Comodoから電子メールで送信されたZipファイルから直接取得されました。

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)

RDPとMDaemonを使用するためにこれらをWindows証明書ストアにインストールしたとき、これらの証明書をを使用してPKCS12ファイルに変換しました。

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

次に、PFXファイルを証明書にインポートしましたMMC自動ストア先を使用したコンピューターアカウントのスナップイン。SSLとTLS> MDaemonの下のMDaemonのセキュリティ設定ダイアログで新しい証明書を選択し、サーバーを再起動します。OpenSSLを使用すると、正しい証明書が中間証明書とともに提供されていることがわかります。

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

Androidの証明書チェーンと、ルートCAがAndroidのCAストアにあるかどうかを確認しました。

予想される完全な証明書チェーンは次のとおりです。以下の名前は一般名（CN）です。

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

AddTrust外部CAルートがAndroid証明書ストアに正しい拇印で存在することを確認しました。

サーバーのTLS証明書から信頼されたルートCAへのパスがないことを示すエラーをK-9Mailがスローするのはなぜですか？

windows-server-2008-r2sslcertificate-authorityssl-certificate-errorsmdaemon
1
Aldaviva

答えはComodoナレッジベースの記事から来ました： Androidでの信頼できない証明書エラー 。

エラーの原因は、デフォルトのWindows証明書ストアにある既存のComodo証明書です。中間証明書の1つであるCOMODO RSA Certification Authorityは、デフォルトで、信頼されたルート証明機関フォルダーに自己発行のCA証明書として存在します。私はそこにインストールしませんでした、Windowsはストックインストールでそれを持っています。実際のCOMODORSA認証局は、それ自体ではなくAddTrustによって発行されており、拇印が一致しないため、なぜそこにあるのかわかりません。さらに、この偽の自己発行のComodo RootCAはAndroid 4.4のルートストアには存在しませんが、拇印を確認しない限り混乱するほど類似したCNを持つ他の3つのComodoCAがあります.ComodoとAddTrustの間のCAの再編成に関連する歴史的な理由があるかもしれません。

KB記事の解決策により、K-9のエラーが修正されました。Windowsの信頼されたルート証明機関から自己発行のCOMODO RSA証明機関を削除します（変更を元に戻す必要がある場合に備えて、実際に別のフォルダーに切り取って貼り付けました、完全に削除するのではなく）。

この偽の証明書により、MDaemonは、上位レベルの中間Comodo証明書が実際にはルート証明書であると想定し、SSLハンドシェイクでK-9に送信しませんでした。これは示されていましたが、s_clientの出力では十分に明らかにされていませんでした。修正前は、MDaemonはチェーンの下位2つの証明書のみを送信し、Androidには3番目の証明書（Comodoドメイン検証）からAddTrustへの信頼パスがありませんでした。2番目の証明書は修正後、MDaemonはチェーンの下位3つの証明書を送信し、AndroidはComodo認定CAからAddTrustへのパスを正常に見つけることができました。

未解決の項目の1つは、Windowsの自動ルートCA更新です。 Comodoは、これらの更新によって不要な証明書が信頼されたルートCAストアに復元されることを警告し、すべてのルートCA更新を無効にすることをお勧めします。この1つの例外を除いて、ルートCAリストを最新の状態に保ちたいので、これは最善の解決策ではないと思います。コンピューターの証明書ストアから特定の証明書を削除して定期的に実行できるプログラムを見つけたり、作成したりすることを検討しています。たぶん、私が書くことができるPowerShellまたはcertmgr.exeベースのスクリプトがあります。少なくとも、ルートCAリストが更新され、不要な証明書が復元されたときに自動監視を追加できる可能性があるため、手動で削除する必要があることはわかっています。

2
Aldaviva