Я установил новый сертификат PositiveSSL от Comodo на компьютер с Windows Server 2008 R2. Я успешно подключился от следующих клиентов
на следующие серверы
Однако, когда я использую K-9 Mail для Android для подключения к MDaemon, я получаю сообщение об ошибке
java.security.cert.CertPathValidatorException: Trust Anchor for certificate path not found
Я предполагаю, что Chrome и K-9 ведут себя по-разному на одном и том же телефоне, потому что Chrome для Android имеет собственное хранилище корневых центров сертификации и не полагается на хранилище корневых центров сертификации ОС Android или, по крайней мере, имеет разную логику проверки доверия.
Я установил сертификаты прямо из ZIP-файла, который Comodo прислал мне по электронной почте:
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)
Когда я установил их в хранилище сертификатов Windows для использования RDP и MDaemon, я преобразовал эти сертификаты в файл 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 Certificates для учетной записи компьютера, используя автоматическое место назначения. Я выбрал новый сертификат в диалоговом окне «Настройки безопасности MDaemon» в разделе «SSL и TLS»> «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 и на то, находится ли корневой ЦС в магазине ЦС Android.
Вот ожидаемая полная цепочка сертификатов. Приведенные ниже имена являются общими именами (CN).
AddTrust External CA Root
└─COMODO RSA Certification Authority
└─COMODO RSA Domain Validation Secure Server CA
└─www.myserver.com
Я видел, что внешний корень CA AddTrust действительно существует в хранилище сертификатов Android с правильным отпечатком.
Почему K-9 Mail выдает ошибку о том, что нет пути от сертификата TLS моего сервера к доверенному корневому ЦС?
Ответ пришел из статьи базы знаний Comodo: Ошибка ненадежного сертификата на Android.
Причина ошибки - существующие сертификаты Comodo в хранилище сертификатов Windows по умолчанию. Один из промежуточных сертификатов, COMODO RSA Certification Authority, по умолчанию присутствует в папке Trusted Root Certification Authorities в качестве сертификата CA, выданного самостоятельно. Туда не устанавливал, в винде есть в стоковой установке. Я не уверен, почему он там, потому что настоящий центр сертификации COMODO RSA выдается AddTrust, а не им самим, и отпечатки пальцев не совпадают. Кроме того, этот поддельный самовыданный Comodo Root CA отсутствует в корневом хранилище Android 4.4, хотя есть три других Comodo CA с CN, достаточно похожими, чтобы ввести в заблуждение, если вы не проверите отпечатки пальцев. Возможно, существует какая-то историческая причина, связанная с реорганизацией CA между Comodo и AddTrust.
Решение из статьи базы знаний исправило ошибку в K-9: удалите самостоятельно созданный центр сертификации COMODO RSA из доверенных корневых центров сертификации Windows (я фактически вырезал и вставил его в другую папку на случай, если мне нужно отменить изменение , вместо того, чтобы удалить его навсегда).
Этот поддельный сертификат заставил MDaemon предположить, что промежуточный сертификат Comodo более высокого уровня на самом деле был корневым сертификатом, и он не отправлял его в квитировании SSL на K-9. Это было указано, но недостаточно очевидно для меня в выводе s_client. До исправления MDaemon отправлял только два нижних сертификата в цепочке, а у Android не было пути доверия от третьего сертификата (проверка домена Comodo) до AddTrust, поскольку второй сертификат отсутствовал в ответе. После исправления MDaemon отправил три нижних сертификата в цепочке, и Android смог успешно найти путь от Comodo Certification CA к AddTrust.
Один нерешенный вопрос - это автоматические обновления корневого центра сертификации Windows. Comodo предупреждает, что эти обновления восстановят нежелательный сертификат в хранилище доверенного корневого ЦС, и рекомендует отключить все обновления корневого ЦС. Я думаю, что это не лучшее решение, потому что я хочу, чтобы список корневых центров сертификации оставался актуальным за одним исключением. Я подумываю о попытке найти или написать программу, которая может удалить данный сертификат из хранилища сертификатов компьютера и периодически запускать его. Может быть, я могу написать сценарий на основе PowerShell или certmgr.exe. По крайней мере, может быть, я смогу добавить некоторый автоматический мониторинг, когда список корневых ЦС обновлен и нежелательный сертификат восстановлен, так что я знаю, что пора удалить его вручную.