CertPathValidatorException z Windows Server i Android Client
Zainstalowałem nowy certyfikat PositiveSSL firmy Comodo na komputerze z systemem Windows Server 2008 R2. Udało mi się połączyć z następującymi klientami
- Chrome na Windows
- Chrome na Androida
- Firefox dla systemu Windows
- Internet Explorer
- Vivaldi dla Windows
- Opera na Windows (zarówno HTTPS, jak i IMAP)
- Podłączanie pulpitu zdalnego dla systemu Windows
na następujące serwery
- Apache z mod_ssl
- Usługi pulpitu zdalnego
- MDaemon
Jednak kiedy używam poczty K-9 dla Androida do łączenia się z MDaemonem, pojawia się błąd
java.security.cert.CertPathValidatorException: Trust Anchor for certificate path not found
Zakładam, że Chrome i K-9 zachowują się inaczej na tym samym telefonie, ponieważ Chrome dla Androida ma własny główny magazyn CA i nie opiera się na głównym magazynie CA systemu Android OS lub przynajmniej ma inną logikę sprawdzania zaufania.
Zainstalowałem certyfikaty bezpośrednio z pliku ZIP, które Comodo przesłał mi e-mailem:
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)
Po zainstalowaniu ich w magazynie certyfikatów systemu Windows do użytku z RDP i MDaemon, przekonwertowałem te certyfikaty na plik PKCS12 przy użyciu
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
a następnie zaimportowano plik PFX do przystawki Certyfikaty MMC dla konta komputera przy użyciu automatycznego miejsca docelowego. Wybrałem nowy certyfikat w oknie dialogowym Ustawienia zabezpieczeń MDaemon w obszarze SSL & TLS & > „MDaemon” i kliknął „Restart Servers”. Korzystając z OpenSSL widzę, że wraz z certyfikatami pośrednimi podawany jest poprawny certyfikat.
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)
---
Spojrzałem na łańcuch certyfikatów w Androidzie i czy główny CA jest w sklepie Android CA.
Oto oczekiwany kompletny łańcuch certyfikatów. Nazwy poniżej są nazwami zwyczajowymi (CN).
AddTrust External CA Root
└─COMODO RSA Certification Authority
└─COMODO RSA Domain Validation Secure Server CA
└─www.myserver.com
Zauważyłem, że zewnętrzny główny CA AddTrust istnieje w magazynie certyfikatów Androida z poprawnym odcisk palca.
Dlaczego K-9 Mail wyświetla błąd, że nie ma ścieżki z certyfikatu TLS mojego serwera do zaufanego głównego urzędu certyfikacji?
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
1 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
Błąd niezaufanego certyfikatu w systemie Android
https://support.comodo.com/ind ... droid
.
Przyczyną błędu są istniejące certyfikaty Comodo w domyślnym magazynie certyfikatów systemu Windows. Jeden z certyfikatów pośrednich,
, domyślnie obecny w folderze Zaufane główne urzędy certyfikacji jako certyfikat wydany przez siebie. Nie instalowałem go tam, w Windows jest w standardowej instalacji. Nie jestem pewien, dlaczego tak jest, ponieważ prawdziwy CA COMODO RSA jest wydawany przez AddTrust, a nie sam, a odciski palców nie pasują. Ponadto tego fałszywego, wydanego przez siebie urzędu certyfikacji Comodo Root nie ma w głównym sklepie systemu Android 4.4, chociaż istnieją trzy inne urzędy certyfikacji Comodo z CN na tyle podobnym, że może być mylące, jeśli nie sprawdzisz swoich odcisków palców. Może istnieć jakiś historyczny powód reorganizacji CA między Comodo i AddTrust.
Rozwiązanie z artykułu KB naprawiony błąd w K-9: Usuń samodzielnie utworzony CA COMODO RSA z zaufanych głównych urzędów certyfikacji systemu Windows (faktycznie wyciąłem go i wkleiłem w innym folderze na wypadek, gdyby trzeba było cofnąć zmianę zamiast usuwać ją na zawsze) .
Ten fałszywy certyfikat doprowadził MDaemon do założenia, że pośredni certyfikat Comodo wyższego poziomu był w rzeczywistości certyfikatem głównym i nie wysłał go w uzgadnianiu SSL na K-9. Zostało to wskazane, ale nie jest to dla mnie wystarczająco oczywiste w danych wyjściowych s_client. Przed naprawą MDaemon wysyłał tylko dwa najniższe certyfikaty w łańcuchu, a Android nie miał ścieżki zaufania z trzeciego certyfikatu (walidacja domeny Comodo) do AddTrust, ponieważ w odpowiedzi brakowało drugiego certyfikatu. Po naprawie MDaemon wysłał trzy najniższe certyfikaty w łańcuchu, a Androidowi udało się znaleźć ścieżkę z Comodo Certification CA do AddTrust.
Nierozwiązanym problemem są automatyczne aktualizacje głównego urzędu certyfikacji systemu Windows. Comodo ostrzega, że te aktualizacje przywracają niechciany certyfikat do magazynu zaufanego głównego urzędu certyfikacji i zaleca wyłączenie wszystkich aktualizacji głównego urzędu certyfikacji. Myślę, że nie jest to najlepsze rozwiązanie, ponieważ chcę aktualizować listę głównych urzędów certyfikacji z jednym wyjątkiem. Myślę o próbie znalezienia lub napisania programu, który może usunąć dany certyfikat z magazynu certyfikatów komputera i uruchamiać go okresowo. Może mógłbym napisać skrypt oparty na PowerShell lub certmgr.exe. Przynajmniej może uda mi się dodać automatyczne monitorowanie, gdy lista głównych urzędów certyfikacji zostanie zaktualizowana, a niechciany certyfikat zostanie przywrócony, więc wiem, że czas go ręcznie usunąć.