Düzenleme: - Soruyu biçimlendirmeye çalıştım ve cevabı benimkinden daha prezentabl bir şekilde kabul etti Blog

İşte asıl sorun.

Bu hatayı alıyorum:

ayrıntılı ileti sun.security.validator.ValidatorException: PKIX yolu oluşturma başarısız oldu:
sun.security.provider.certpath.SunCertPathBuilderException: istenen hedefe yönelik geçerli sertifika yolu bulunamıyor

neden javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX yolu oluşturma başarısız oldu: sun.security.provider.certpath.SunCertPathBuilderException: istenen hedefe geçerli sertifika yolu bulunamadı

Tomcat 6'yı web sunucusu olarak kullanıyorum. Farklı Tomcats'lara farklı bağlantı noktalarında ancak aynı makinede yüklü iki HTTPS web uygulamam var. Söyle App1(port 8443)ve App2(port 443). App1bağlanır App2. Ne zaman App1bağlanır App2yukarıdaki hatayı alıyorum. Bunun çok yaygın bir hata olduğunu biliyorum, bu yüzden farklı forumlarda ve sitelerde birçok çözümle karşılaştım. Her server.xmliki Tomcat'ta da aşağıdaki girişe sahibim :

keystoreFile="c:/.keystore" 
keystorePass="changeit"

Her site, app2 tarafından verilen sertifikanın güvenilir uygulama1 jvm deposunda olmamasının aynı nedenini söylüyor. IE tarayıcısında aynı URL'yi vurmaya çalıştığımda da bu doğru görünüyor (ısınma ile bu web sitesinin güvenlik sertifikasında bir sorun var. Burada bu web sitesine devam diyorum). Ancak aynı URL Java istemcisi tarafından vurulduğunda (benim durumumda) yukarıdaki hatayı alıyorum. Güven mağazasına koymak için şu üç seçeneği denedim:

Seçenek 1

System.setProperty("javax.net.ssl.trustStore", "C:/.keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

Seçenek2 Ortam değişkeninde aşağıdaki ayar

CATALINA_OPTS -- param name
-Djavax.net.ssl.trustStore=C:\.keystore -Djavax.net.ssl.trustStorePassword=changeit ---param value

Seçenek3 Ortam değişkeninde aşağıdaki ayar

JAVA_OPTS -- param name
-Djavax.net.ssl.trustStore=C:\.keystore -Djavax.net.ssl.trustStorePassword=changeit ---param value

Ama hiçbir şey işe yaramadı .

İşlenmiş sonunda neler önerilen Java yaklaşımını yürütülüyor Apache HttpClient ile geçersiz SSL sertifikaları nasıl baş edilir? Pascal Thivent tarafından yani InstallCert programının yürütülmesi.

Ancak bu yaklaşım geliştirici kurulumu için iyidir, ancak üretim ortamında kullanamam.

Ben de aynı değerleri belirtmiştik zaman üç yaklaşım yukarıda işi yoktu sözü niye merak ediyorum server.xmlait app2ayarıyla truststore sunucu ve aynı değerlerle

System.setProperty("javax.net.ssl.trustStore", "C:/.keystore") and System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

içinde app1programa.

Daha fazla bilgi için bağlantıyı şu şekilde yapıyorum:

URL url = new URL(urlStr);

URLConnection conn = url.openConnection();

if (conn instanceof HttpsURLConnection) {

  HttpsURLConnection conn1 = (HttpsURLConnection) url.openConnection();

  conn1.setHostnameVerifier(new HostnameVerifier() {
    public boolean verify(String hostname, SSLSession session) {
      return true;
    }
  });

  reply.load(conn1.getInputStream());

App2 sertifikasını adresinde kullanılan JVM'nin güven deposu dosyasına eklemeniz gerekir %JAVA_HOME%\lib\security\cacerts.

İlk olarak, aşağıdaki komutu çalıştırarak sertifikanızın zaten güven deposunda olup olmadığını kontrol edebilirsiniz: keytool -list -keystore "%JAVA_HOME%/jre/lib/security/cacerts"(şifre girmeniz gerekmez)

Sertifikanız eksikse, tarayıcınızla indirerek aşağıdaki komutla güven deposuna ekleyebilirsiniz:

keytool -import -noprompt -trustcacerts -alias <AliasName> -file <certificate> -keystore <KeystoreFile> -storepass <Password>

İçe aktardıktan sonra sertifikanızın eklenip eklenmediğini kontrol etmek için ilk komutu tekrar çalıştırabilirsiniz.

Sun / Oracle bilgilerine buradan ulaşabilirsiniz .

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX yolu oluşturma başarısız oldu: sun.security.provider.certpath.SunCertPathBuilderException: istenen hedefe geçerli sertifika yolu bulunamadı

• Hatayı aldığımda, Google'ın ifadenin anlamını çıkarmaya çalıştım ve buldum, bu sorun bir sunucu HTTPS SSL sertifikasını değiştirdiğinde ve eski java sürümümüz kök sertifika yetkilisini (CA) tanımıyorsa oluşur .

• Tarayıcınızda HTTPS URL'sine erişebiliyorsanız, Java'yı kök CA'yı tanıyacak şekilde güncellemek mümkündür.

• Tarayıcınızda, Java'nın erişemediği HTTPS URL'sine gidin. HTTPS sertifika zincirine tıklayın (Internet Explorer'da kilit simgesi var), sertifikayı görüntülemek için kilidi tıklayın.

• Sertifikanın “Ayrıntılar” a ve “Dosyaya kopyala” ya gidin. Base64 (.cer) formatında kopyalayın . Masaüstünüze kaydedilecektir.

• Tüm uyarıları yoksayarak sertifikayı yükleyin.

• Erişmeye çalıştığım URL'nin sertifika bilgilerini bu şekilde topladım.

Artık java sürümümü sertifika hakkında bilmek zorunda kaldım, böylece daha fazla URL'yi tanımayı reddetmez. Bu bağlamda, kök sertifika bilgilerinin varsayılan olarak JDK'nın \ jre \ lib \ güvenlik konumunda kaldığını ve erişilecek varsayılan parolanın: changeit olduğunu belirtmem gerekir .

Cacerts bilgisini görüntülemek için aşağıdaki prosedürler şunlardır:

• Başlat Düğmesine tıklayın -> Çalıştır

• cmd yazın. Komut istemi açılır (yönetici olarak açmanız gerekebilir).

Sizin için • Git Java/jreX/bindizinine

• Aşağıdakileri yazın

keytool -list -keystore D: \ Java \ jdk1.5.0_12 \ jre \ lib \ security \ cacerts

Anahtar deposunda bulunan geçerli sertifikaların listesini verir. Şuna benziyor:

C: \ Belgeler ve Ayarlar \ NeelanjanaG> keytool -list -keystore D: \ Java \ jdk1.5.0_12 \ jre \ lib \ security \ cacerts

Anahtar deposu şifresini girin: changeit

Anahtar deposu türü: jks

Anahtar deposu sağlayıcısı: SUN

Anahtar deponuz 44 kayıt içeriyor

verisignclass3g2ca, 26 Mar 2004, güvenilirCertEntry,

Sertifika parmak izi (MD5): A2: 33: 9B: 4C: 74: 78: 73: D4: 6C: E7: C1: F3: 8D: CB: 5C: E9

entrustclientca, 9 Ocak 2003, TrustedCertEntry,

Sertifika parmak izi (MD5): 0C: 41: 2F: 13: 5B: A0: 54: F5: 96: 66: 2D: 7E: CD: 0E: 03: F4

thawtepersonalbasicca, 13 Şub 1999, TrustedCertEntry,

Sertifika parmak izi (MD5): E6: 0B: D2: C9: CA: 2D: 88: DB: 1A: 71: 0E: 4B: 78: EB: 02: 41

addtrustclass1ca, 1 Mayıs 2006, TrustedCertEntry,

Sertifika parmak izi (MD5): 1E: 42: 95: 02: 33: 92: 6B: B9: 5F: C0: 7F: DA: D6: B2: 4B: FC

verisignclass2g3ca, 26 Mar 2004, güvenilirCertEntry,

Sertifika parmak izi (MD5): F8: BE: C4: 63: 22: C9: A8: 46: 74: 8B: B8: 1D: 1E: 4A: 2B: F6

• Şimdi daha önce kurulmuş olan sertifikayı cacerlere dahil etmek zorunda kaldım.

• Bunun için prosedür aşağıdadır:

keytool –import –noprompt –trustcacerts –alias ALIASNAME -file FILENAME_OF_THE_INSTALLED_CERTIFICATE -anahtar deposu PATH_TO_CACERTS_FILE -storepass PASSWORD

Java 7 kullanıyorsanız:

keytool –importcert –trustacerts –alias ALIASNAME -file PATH_TO_FILENAME_OF_THE_INSTALLED_CERTIFICATE -keystore PATH_TO_CACERTS_FILE -storepass değişikliği

• Daha sonra sertifika bilgilerini cacert dosyasına ekler.

Yukarıda belirtilen İstisna için bulduğum çözüm !!

Nasıl çalışır in Tomcat 7

Tomcat Uygulamasında kendinden imzalı bir sertifikayı desteklemek istedim, ancak aşağıdaki snippet çalışmadı

import java.io.DataOutputStream;
import java.net.HttpURLConnection;
import java.net.URL;

public class HTTPSPlayground {
    public static void main(String[] args) throws Exception {

        URL url = new URL("https:// ... .com");
        HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();

        httpURLConnection.setRequestMethod("POST");
        httpURLConnection.setRequestProperty("Accept-Language", "en-US,en;q=0.5");
        httpURLConnection.setDoOutput(true);
        DataOutputStream wr = new DataOutputStream(httpURLConnection.getOutputStream());

        String serializedMessage = "{}";
        wr.writeBytes(serializedMessage);
        wr.flush();
        wr.close();

        int responseCode = httpURLConnection.getResponseCode();
        System.out.println(responseCode);
    }
}

sorunumu çözen budur:

1) .crtDosyayı indirin

echo -n | openssl s_client -connect <your domain>:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ~/<your domain>.crt

• <your domain>alan adınızla değiştirin (ör. jossef.com)

2) .crtDosyayı Java'nın cacertssertifika deposuna uygulayın

keytool -import -v -trustcacerts -alias <your domain> -file ~/<your domain>.crt -keystore <JAVA HOME>/jre/lib/security/cacerts -keypass changeit -storepass changeit

• <your domain>alan adınızla değiştirin (ör. jossef.com)
• <JAVA HOME>java ana dizininizle değiştirin

3) Kes

İv'e sertifikamı Javavarsayılan sertifika depolarına yüklemiş olsa da Tomcat bunu görmezden geliyor (Java'nın varsayılan sertifika depolarını kullanacak şekilde yapılandırılmamış gibi görünüyor).

Bunu kesmek için kodunuzda bir yere aşağıdakileri ekleyin:

String certificatesTrustStorePath = "<JAVA HOME>/jre/lib/security/cacerts";
System.setProperty("javax.net.ssl.trustStore", certificatesTrustStorePath);

// ...

Benim durumumda sorun, web sunucusunun kök CA'yı değil, yalnızca sertifikayı ve ara CA'yı göndermesidir. Bu JVM seçeneğini eklemek sorunu çözdü:-Dcom.sun.security.enableAIAcaIssuers=true

Authority Information Access uzantısının caIssuers erişim yöntemi için destek mevcuttur. Uyumluluk için varsayılan olarak devre dışıdır ve system özelliği com.sun.security.enableAIAcaIssuerstrue değerine ayarlanarak etkinleştirilebilir .

True olarak ayarlanırsa, Sun'ın CertPathBuilder uygulamasının PKIX uygulaması, ldap, http veya ftp türünde bir URI olması koşuluyla, veren CA sertifikasını bulmak için bir sertifikanın AIA uzantısındaki bilgileri (belirtilen CertStores'a ek olarak) kullanır.

Kaynak

Başka bir neden, JDK'nın eski bir sürümü olabilir. JDk 1.8.0_60 sürümünü kullanıyordum, en son sürüme güncellemek sertifika sorununu çözdü.

Cacerts dosyam tamamen boştu. Bunu cacerts dosyasını Windows makinemden (Oracle Java 7 kullanan) kopyalayarak ve Linux kutusuna (OpenJDK) scp'd yaparak çözdüm.

cd %JAVA_HOME%/jre/lib/security/
scp cacerts mylinuxmachin:/tmp

ve sonra linux makinesinde

cp /tmp/cacerts /etc/ssl/certs/java/cacerts

Şimdiye kadar harika çalıştı.

Benim için bu hata, SSL'yi işleyen bir NGINX ters proxy'nin arkasındaki bir işleme bağlanmaya çalışırken de ortaya çıktı.

Sorunun, tüm sertifika zincirinin birleştirilmiş olmadığı bir sertifika olduğu ortaya çıktı. Ara sertifikalar eklediğimde sorun çözüldü.

Bu yardımcı olur umarım.

Tomcat 7'yi Linux altında kullanmak, hile yaptı.

String certificatesTrustStorePath = "/etc/alternatives/jre/lib/security/cacerts";
System.setProperty("javax.net.ssl.trustStore", certificatesTrustStorePath);
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

Linux altında, $JAVA_HOMEher zaman kurulum değildir, ama genellikle /etc/alternatives/jreişaret$JAVA_HOME/jre

Aşağıdaki kod benim için çalışıyor:

import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

import javax.net.ssl.X509TrustManager;

public class TrustAnyTrustManager implements X509TrustManager {

public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
}

public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
}

public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[] {};
}
}

HttpsURLConnection conn = null;
            URL url = new URL(serviceUrl);
            conn = (HttpsURLConnection) url.openConnection();
             SSLContext sc = SSLContext.getInstance("SSL");  
             sc.init(null, new TrustManager[]{new TrustAnyTrustManager()}, new java.security.SecureRandom());  

             conn.setSSLSocketFactory(sc.getSocketFactory());

Kullanıyordum jdk1.8.0_171Aynı sorunla karşılaştığımda . Burada en iyi 2 çözümü denedim (keytool ve bir hack olan başka bir çözüm kullanarak bir sertifika ekleyerek) ama onlar benim için çalışmadı.

JDK'mı yükselttim 1.8.0_181ve bir cazibe gibi çalıştı.

program dosyalarındaki tüm java sürümlerini arayan ve onlara bir sertifika ekleyen küçük bir win32 (WinXP 32bit testet) aptal cmd (komut satırı) komut dosyası yazdım. Şifrenin varsayılan "changeit" olması veya kodda kendiniz değiştirmeniz gerekir :-)

@echo off

for /F  %%d in ('dir /B %ProgramFiles%\java') do (
    %ProgramFiles%\Java\%%d\bin\keytool.exe -import -noprompt -trustcacerts -file some-exported-cert-saved-as.crt -keystore %ProgramFiles%\Java\%%d\lib\security\cacerts -storepass changeit
)

pause

Aşağıdaki MacOS X için, çalışan 'importcert' seçeneğinde çift hipen ile denemek zorunda kaldığım tam komut benim için çalıştı:

sudo keytool -–importcert -file /PathTo/YourCertFileDownloadedFromBrowserLockIcon.crt -keystore /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/security/cacerts -alias "Cert" -storepass changeit

Benim için bu yayından tanınan çözümü çalışmadı: https://stackoverflow.com/a/9619478/4507034 .

Bunun yerine, sertifikayı makinenin güvenilir sertifikalarıma aktararak sorunu çözmeyi başardım.

Adımlar:

1. https://localhost:8443/yourpathSertifikanın çalışmadığı URL'ye (ör. ) Gidin .
2. Sertifikayı belirtilen postada açıklandığı şekilde dışa aktarın.
3. Windows makinenizde açık: Manage computer certificates
4. Git Trusted Root Certification Authorities->Certificates
5. your_certification_name.cerDosyanızı buraya aktarın .

Ubuntu sunucusunda çalışan Tomcat için hangi Java'nın kullanıldığını bulmak için "ps -ef | grep tomcat" komutunu kullanın:

Örneklem:

/home/mcp01$ **ps -ef |grep tomcat**
tomcat7  28477     1  0 10:59 ?        00:00:18 **/usr/local/java/jdk1.7.0_15/bin/java** -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties -Djava.awt.headless=true -Xmx512m -XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/tmp/tomcat7-tomcat7-tmp org.apache.catalina.startup.Bootstrap start
1005     28567 28131  0 11:34 pts/1    00:00:00 grep --color=auto tomcat

Sonra şu adrese gidebiliriz: cd /usr/local/java/jdk1.7.0_15/jre/lib/security

Varsayılan cacerts dosyası burada bulunur. Güvenilmeyen sertifikayı içine yerleştirin.

güvenlik için uygulamamızda kendinden imzalı sertifikalar kullanmamalıyız. Bununla birlikte, geliştirme söz konusu olduğunda, genellikle kendinden imzalı sertifikalara sahip deneme ortamlarını kullanmak zorundayız. Kodumda programlı olarak bu sorunu düzeltmeye çalıştım ve başarısız. Ancak, sertifikayı jre trust-store'a ekleyerek sorunumu çözdüm. Lütfen aşağıdaki adımları bulun,

1. Site sertifikasını indirin,

   • Chrome'u kullanma
   • Firefox'u kullanma

2. Sertifikayı (örn: cert_file.cer) $ JAVA_HOME \ Jre \ Lib \ Security dizinine kopyalayın

3. CMD'yi Yönetici'de açın ve dizini $ JAVA_HOME \ Jre \ Lib \ Security olarak değiştirin

4. Aşağıdaki komutu kullanarak sertifikayı bir güven deposuna aktarın,

keytool -import -alias ca -file cert_file.cer -keystore cacerts -storepass changeit

Keytool'un tanınamayacağını söyleyen bir hatayla karşılaşırsanız lütfen buna bakın.

Tip evet gibi aşağıda

Bu sertifikaya güvenin: [Evet]

5. Şimdi kodunuzu çalıştırmayı deneyin veya java kullanarak URL'ye programlı olarak erişin.

Güncelleme

Uygulama sunucunuz jboss ise aşağıdaki sistem özelliğini eklemeyi deneyin

System.setProperty("org.jboss.security.ignoreHttpsHost","true");

Bu yardımcı olur umarım!

TAŞINABİLİR ÇÖZÜM (Alpine Linux)

Bu sorunu uygulama ortamlarımızda giderebilmek için Linux terminal komutlarını aşağıdaki gibi hazırladık:

cd ~

Giriş dizininde cert dosyası oluşturur.

apk add openssl

Bu komut, Alp Linux'ta openssl'yi kurar. Diğer Linux dağıtımları için uygun komutları bulabilirsiniz.

openssl s_client -connect <host-dns-ssl-belongs> < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt

Gerekli sertifika dosyasını oluşturdu.

sudo $JAVA_HOME/bin/keytool -import -alias server_name -keystore $JAVA_HOME/lib/security/cacerts -file public.crt -storepass changeit -noprompt

Oluşturulan dosyayı 'keytool' programı ile JRE'ye uyguladı.

Not: Lütfen DNS'inizi değiştirin<host-dns-ssl-belongs>

Not2: Lütfen -nopromptdoğrulama mesajını istemeyeceğinizi (evet / hayır) ve -storepass changeitparametrenin şifre istemini devre dışı bırakacağını ve gerekli şifreyi sağlayacağını (varsayılan olarak 'changeit') unutmayın. Bu iki özellik, bu komut dosyalarını bir Docker görüntüsü oluşturmak gibi uygulama ortamlarınızda kullanmanızı sağlar.

Not3 Uygulamanızı Docker aracılığıyla dağıtıyorsanız, gizli dosyayı bir kez oluşturabilir ve uygulama proje dosyalarınıza koyabilirsiniz. Tekrar tekrar oluşturmanız gerekmeyecek.

Benim de bu problemim var.

SSL anahtarını .keystore'a ekleyerek neredeyse her şeyi denedim, ancak Java1_6_x ile çalışmadı. Benim için Java'nın daha yeni bir sürümünü, Java1_8_x'i JVM olarak kullanmaya başlarsak yardımcı oldu.

Proxy arkasındayken Android Studio ile bu sorunu yaşıyordum. Bir derleme sırasında eşleme dosyasını yüklemeye çalışan Crashlytics kullanıyordum.

Eksik proxy sertifikasını adresindeki truststore'a ekledim /Users/[username]/Documents/Android Studio.app/Contents/jre/jdk/Contents/Home/jre/lib/security/cacerts

aşağıdaki komutla: keytool -import -trustcacerts -keystore cacerts -storepass [password] -noprompt -alias [alias] -file [my_certificate_location]

örneğin varsayılan güven deposu şifresi ile keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias myproxycert -file /Users/myname/Downloads/MyProxy.crt

Sadece küçük bir hack. "Hudson.model.UpdateCenter.xml" dosyasındaki URL'yi https'den http'ye güncelleyin

<?xml version='1.1' encoding='UTF-8'?>
<sites>
  <site>
    <id>default</id>
    <url>http://updates.jenkins.io/update-center.json</url>
  </site>
</sites>

Java dosyaları indirmek zorunda bir QEMU ortamı var çünkü ben chime istiyorum. Bu çıkıyor /etc/ssl/certs/java/cacertso eşleşmediğinden QEMU sorunu var/etc/ssl/certs/java/cacerts konak ortamında. Ana bilgisayar ortamı bir şirket proxy'sinin arkasındadır, bu nedenle java cacerts özelleştirilmiş bir sürümdür.

QEMU ortamı kullanıyorsanız, önce ana bilgisayar sisteminin dosyalara erişebildiğinden emin olun. Örneğin, bu komut dosyasını deneyebilirsiniz ilk önce ana makinenizde . Komut dosyası ana makinede iyi çalışıyor ancak QEMU'da çalışmıyorsa, benimle aynı sorunu yaşıyorsunuz.

Bu sorunu çözmek için, QEMU'daki orijinal dosyanın yedeğini almak, ana bilgisayardaki dosyayı QEMU chroot hapishanesine kopyalamak zorunda kaldım ve sonra java dosyaları QEMU'da normal olarak indirebilir.

Daha iyi bir çözüm /etcQEMU ortamına monte edilebilir ; ancak diğer dosyaların bu işlemden etkilenip etkilenmeyeceğinden emin değilim. Bu yüzden bu çirkin ama kolay çözümü kullanmaya karar verdim.

Bu kötü şöhretli PKIX hata mesajı için olası başka bir nedeni belgelemek için herhangi bir yer gibi görünüyor. Anahtar deposu ve truststore içeriklerine ve çeşitli java kurulum yapılandırmalarına bakarak çok uzun zaman geçirdikten sonra sorunumun bir yazım hatası olduğunu fark ettim.

Yazım hatası anahtar deposunu truststore olarak kullandığım anlamına geliyordu. Şirketlerim Kök CA anahtar deposunda bağımsız bir sertifika olarak değil, sadece bir sertifika zincirinin parçası olarak tanımlandı ve başka bir yerde tanımlanmadı (yani, cacerts) PKIX hatası almaya devam ettim.

Başarısız bir sürümden sonra (bu prod yapılandırma, başka bir yerde ok) ve iki gün baş tırmalama sonra nihayet yazım hatası gördüm ve şimdi hepsi iyi.

Umarım bu birine yardımcı olur.

bunu kodunuza ekleyin:

TrustManager[] trustAllCerts = new TrustManager[]{
           new X509TrustManager() {
               @Override
               public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                   return new X509Certificate[0];
               }

               @Override
               public void checkClientTrusted(
                       java.security.cert.X509Certificate[] certs, String authType) {
               }

               @Override
               public void checkServerTrusted(
                       java.security.cert.X509Certificate[] certs, String authType) {
               }
           }
       };

       try {
           SSLContext sc = SSLContext.getInstance("SSL");
           sc.init(null, trustAllCerts, new java.security.SecureRandom());
           HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
       } catch (GeneralSecurityException e) {
       }