Certyfikat jest zaufany przez komputer, ale nie przez Androida

Od dziś rano mój certyfikat nie jest już zaufany na Androidzie i moja aplikacja nie może się już połączyć:

 Catch exception while startHandshake: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
 return an invalid session with invalid cipher suite of SSL_NULL_WITH_NULL_NULL
 javax.net.ssl.SSLPeerUnverifiedException: No peer certificate
    at org.apache.harmony.xnet.provider.jsse.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:137)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:93)
    at org.apache.http.conn.ssl.SSLSocketFactory.createSocket(SSLSocketFactory.java:381)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:165)
    at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:164)
    at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:119)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:360)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:591)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:807)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:781)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:770)

Jeśli spróbuję w Google Chrome (na komputerze PC), nie ma problemu i certyfikat jest zaufany, ale jeśli spróbuję w przeglądarce Chrome na Androidzie, otrzymam informację, że certyfikat nie jest zaufany. Co mogę zrobić?

W pliku certyfikatów może brakować certyfikatu pośredniego. Jeśli odwiedziłeś już inną witrynę, która ma tego samego sprzedawcę certyfikatów, certyfikat pośredni zostanie zapamiętany w Twojej przeglądarce. Może to nie być - lub nawet lepiej - nie będzie w przypadku każdego odwiedzającego Twoją witrynę. Aby rozwiązać brakujący certyfikat pośredni w połączeniu SSL, musisz dodać certyfikat pośredni do własnego pliku certyfikatu.

GoDaddy ma pewne informacje na temat certyfikatów pośrednich (ale najlepszym źródłem jest zawsze dostawca certyfikatu): http://support.godaddy.com/help/article/868/what-is-an-intermediate-certificate

Kiedyś miałem problem z certyfikatem pośrednim (również z Commodo) i musiałem połączyć mój własny plik certyfikatu z pośrednimi CA, aby działał. Po wykonaniu tej czynności nie wystąpiły już żadne błędy.

Instrukcje instalacji dla serwera internetowego firmy Godaddy: http://support.godaddy.com/help/article/5346/installing-an-ssl-server-instructions?locale=en

A oto lista najpopularniejszych przewodników instalacyjnych autorstwa Commodo: https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/1145/0/how-do-i-make- mój-własny-plik-pakietu-z-plików-crt

W zależności od używanego serwera WWW, musisz określić wszystkie certyfikaty (certyfikat domeny, pośredni i główny) lub połączyć je w jeden (np. Dla Nginx) w kolejności:

1. certyfikat domeny
2. certyfikat pośredni
3. certyfikat główny

Prostym sposobem na zrobienie tego w terminalu SSH jest wpisanie:

cat domainfile intermediatefile rootfile > targetfile

Narzędzie do testowania certyfikatów

Jeśli napotkasz dalsze problemy lub nie masz pewności, czy certyfikat jest prawidłowy, wypróbuj narzędzie online, aby zweryfikować certyfikat SSL. Na przykład: networking4all.com/en/ssl+certificates/quickscan

Obsługa SNI dla Androida 2.2 i starszych

Należy pamiętać, że Android 2.2 (i prawdopodobnie starszy) nie obsługuje SNI, co pozwala na działanie wielu certyfikatów SSL dla różnych nazw hostów bez problemów na jednym adresie IP. Podziękowania dla @technyquist za dostarczenie tych informacji. Proszę przejrzeć to pytanie SO dotyczące SNI, aby uzyskać więcej informacji na ten temat.

Musisz utworzyć pakiet crt, wtedy będzie dobrze. Otrzymasz trzy pliki CRT. Użyj ich wszystkich! Jeśli korzystałeś tylko z domain.crt, pojawi się ostrzeżenie na Androidzie, ale nie na komputerze.

Jestem na nginx. Otworzyłem domain_name.crt, a następnie otworzyłem positivesslca2.crt, wybierz wszystko i skopiuj na koniec nazwa_domeny.crt. Następnie otwórz AddTrustExternalCARoot.crt, skopiuj ponownie na koniec nazwa_domeny.crt. Następnie zainstaluj plik domain_name.crt

działa dobrze.

Dodanie tego tutaj, ponieważ może to komuś pomóc. Miałem problemy z Androidem wyświetlającym wyskakujące okienko i błąd nieprawidłowego certyfikatu.

Posiadamy certyfikat Comodo Extended Validation i otrzymaliśmy plik zip, który zawierał 4 pliki:

• AddTrustExternalCARoot.crt
• COMODORSAAddTrustCA.crt
• COMODORSAExtendedValidationSecureServerCA.crt
• www_mydomain_com.crt

Połączyłem je wszystkie razem w jednej linii, w ten sposób:

cat www_mydomain_com.crt COMODORSAExtendedValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt >www.mydomain.com.ev-ssl-bundle.crt

Następnie użyłem tego pliku pakietu jako mojego ssl_certificate_keyw nginx. To wszystko, teraz działa.

Zainspirowany tym sednem: https://gist.github.com/ipedrazas/6d6c31144636d586dcc3

Z Comodo PositiveSSL otrzymaliśmy 4 pliki.

• AddTrustExternalCARoot.crt
• COMODORSAAddTrustCA.crt
• COMODORSADomainValidationSecureServerCA.crt
• nasza_domena.crt

Gdy postępowaliśmy zgodnie z instrukcjami na stronie comodo - otrzymywaliśmy błąd, że w naszym certyfikacie brakowało pośredniego pliku certyfikatu.

Zasadniczo składnia to

cat our_domain.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt  AddTrustExternalCARoot.crt > domain-ssl_bundle.crt

Niedawno poradziłem sobie z tym problemem z Commodo cert, który kupiłem na ssls.com i mam 3 pliki:

nazwa-domeny.ca-bundle nazwa-domeny.crt i nazwa-domeny.p7b

Musiałem to ustawić na Nginx i to jest polecenie, które wykonałem:

cat domain-name.ca-bundle domain-name.crt > commodo-ssl-bundle.crt

Następnie użyłem commodo-ssl-bundle.crt wewnątrz pliku konfiguracyjnego Nginx i działa jak urok.

Miałem ten sam problem, a moim problemem było to, że urządzenie nie miało odpowiedniej daty i godziny. Raz naprawiłem, że certyfikat jest zaufany.

Wystąpił ten sam błąd, ponieważ nie wystawiłem certyfikatu Let's Encrypt dla www .my-domain.com, tylko dla my-domain.com

Wydanie również na www. i skonfigurowanie vhosta w celu załadowania certyfikatów dla www .moja-domena.com przed przekierowaniem do https://moja-domena.com załatwiło sprawę .

Napotkałem ten sam problem w Apache 2.2, kiedy próbowałem użyć wielu SSLCertificateChainFiledyrektyw dla każdego certyfikatu pośredniego; zamiast tego musiałem połączyć wszystkie trzy w jeden plik. Pochodząc z GoDaddy, gdzie zrobili to dla mnie jako „pakiet”, ten dodatkowy krok był dla mnie nowy, ale ponowne przeczytanie dokumentacji Apache pokazało to wyraźnie.

Warto zauważyć, że ta dyrektywa jest przestarzała od Apache 2.4.8, ponieważ można teraz łączyć wszystkie elementy pośrednie z rzeczywistym cert.

Mam nadzieję, że nie jestem za późno, to rozwiązanie tutaj zadziałało, używam COMODO SSL, powyższe rozwiązania z czasem wydają się nieaktualne, moja strona lifetanstic.co.ke

Zamiast kontaktować się z pomocą techniczną Comodo i uzyskać plik pakietu CA, możesz wykonać następujące czynności:

Kiedy otrzymasz nowy certyfikat SSL od Comodo (pocztą), dołączony jest plik zip. Musisz rozpakować plik zip i otworzyć następujące pliki w edytorze tekstu, takim jak notatnik:

AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt

Następnie skopiuj tekst każdego pliku „.crt” i wklej teksty nad sobą w polu „Pakiet urzędu certyfikacji (opcjonalne)”.

Następnie po prostu dodaj certyfikat SSL jak zwykle w polu „Certyfikat” i kliknij przycisk „Autofilowanie według certyfikatu” i naciśnij „Instaluj”.

Z certyfikatami GoDaddy najprawdopodobniej będziesz mieć domain.key, gd_bundle_something.crti (losowy ciąg alfanumeryczny)4923hg4k23jh4.crt

Musisz: cat gd_bundle_something.crt >> 4923hg4k23jh4.crt

A potem na nginx użyjesz

ssl                  on;
ssl_certificate      /etc/ssl/certs/4923hg4k23jh4.crt;
ssl_certificate_key  /etc/ssl/certs/domain.key;

Miałem ten sam problem. Inny sposób wygenerowania poprawnego pliku .crt wygląda następująco:

Czasami otrzymujesz plik .PEM zawierający cały łańcuch certyfikatów. Plik może wyglądać następująco ....

-----BEGIN RSA PRIVATE KEY-----
blablablabase64private...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
blablablabase64CRT1...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
blablablabase64CRT2...
-----END CERTIFICATE-----
...

Jeśli usuniesz całą private keysekcję, będziesz mieć poprawny plik .crt

Upewnij się, że używasz również pośredniego pliku crt (plik .crt z pakietem ... niektórzy dostawcy nazywają go również pakietem lub certyfikatem CA). następnie w swoim ssl.conf,

SSLCertificateFile </path/for/actual/certificate>

SSLCACertificateFile </path/for/actual/intermediate_certificate>

następnie zrestartuj serwer WWW: ex do użytku w Apache:

sudo service httpd restart

Możliwe, że brakuje Ci certyfikatu na urządzeniu.

spróbuj spojrzeć na tę odpowiedź: Jak zainstalować zaufany certyfikat CA na urządzeniu z Androidem? aby zobaczyć, jak zainstalować urząd certyfikacji na swoim urządzeniu.

Miałem podobny problem i napisałem o nim szczegółowy artykuł. Jeśli ktoś ma ten sam problem, zapraszam do przeczytania mojego artykułu.

https://developer-blog.net/administration/ssl-zertifikat-installieren/

Jest to szczegółowy opis problemu w języku niemieckim.