Próbuję uzyskać tweety za pomocą biblioteki twitter4j dla mojego projektu Java. Przy pierwszym uruchomieniu dostałem błąd dotyczący certyfikatu sun.security.validator.ValidatorException
i sun.security.provider.certpath.SunCertPathBuilderException
. Następnie dodałem certyfikat Twittera przez:
C:\Program Files\Java\jdk1.7.0_45\jre\lib\security>keytool -importcert -trustcacerts -file PathToCert -alias ca_alias -keystore "C:\Program Files\Java\jdk1.7.0_45\jre\lib\security\cacerts"
Ale bez powodzenia. Oto procedura pobierania tweetów:
public static void main(String[] args) throws TwitterException {
ConfigurationBuilder cb = new ConfigurationBuilder();
cb.setDebugEnabled(true)
.setOAuthConsumerKey("myConsumerKey")
.setOAuthConsumerSecret("myConsumerSecret")
.setOAuthAccessToken("myAccessToken")
.setOAuthAccessTokenSecret("myAccessTokenSecret");
TwitterFactory tf = new TwitterFactory(cb.build());
Twitter twitter = tf.getInstance();
try {
Query query = new Query("iphone");
QueryResult result;
result = twitter.search(query);
System.out.println("Total amount of tweets: " + result.getTweets().size());
List<Status> tweets = result.getTweets();
for (Status tweet : tweets) {
System.out.println("@" + tweet.getUser().getScreenName() + " : " + tweet.getText());
}
} catch (TwitterException te) {
te.printStackTrace();
System.out.println("Failed to search tweets: " + te.getMessage());
}
A oto błąd:
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Relevant discussions can be found on the Internet at:
http://www.google.co.jp/search?q=d35baff5 or
http://www.google.co.jp/search?q=1446302e
TwitterException{exceptionCode=[d35baff5-1446302e 43208640-747fd158 43208640-747fd158 43208640-747fd158], statusCode=-1, message=null, code=-1, retryAfter=-1, rateLimitStatus=null, version=3.0.5}
at twitter4j.internal.http.HttpClientImpl.request(HttpClientImpl.java:177)
at twitter4j.internal.http.HttpClientWrapper.request(HttpClientWrapper.java:61)
at twitter4j.internal.http.HttpClientWrapper.get(HttpClientWrapper.java:81)
at twitter4j.TwitterImpl.get(TwitterImpl.java:1929)
at twitter4j.TwitterImpl.search(TwitterImpl.java:306)
at jku.cc.servlets.TweetsAnalyzer.main(TweetsAnalyzer.java:38)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker.process_record(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
at twitter4j.internal.http.HttpResponseImpl.<init>(HttpResponseImpl.java:34)
at twitter4j.internal.http.HttpClientImpl.request(HttpClientImpl.java:141)
... 5 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(Unknown Source)
at sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
at sun.security.validator.Validator.validate(Unknown Source)
at sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
... 20 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source)
at java.security.cert.CertPathBuilder.build(Unknown Source)
... 26 more
Failed to search tweets: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Odpowiedzi:
"more info" > "security" > "show certificate" > "details" > "export.."
. Odbierz nazwę i wybierz typ pliku example.cerTeraz masz plik z magazynem kluczy i musisz go dodać do JVM. Określ lokalizację plików cacerts, np.
C:\Program Files (x86)\Java\jre1.6.0_22\lib\security\cacerts.
Następnie zaimportuj
example.cer
plik do cacerts w wierszu poleceń:keytool -import -alias example -keystore C:\Program Files (x86)\Java\jre1.6.0_22\lib\security\cacerts -file example.cer
Zostaniesz poproszony o podanie hasła, które jest domyślne
changeit
Uruchom ponownie JVM / PC.
źródło: http://magicmonster.com/kb/prg/java/ssl/pkix_path_building_failed.html
źródło
alias
nazwa certyfikatu w wierszu poleceń powinna być unikalna.Po wielu godzinach prób zbudowania plików certyfikatów, aby moja instalacja Java 6 działała z nowymi certyfikatami Twitter, w końcu natknąłem się na niezwykle proste rozwiązanie ukryte w komentarzu na jednym z forów dyskusyjnych. Po prostu skopiuj plik cacerts z instalacji Java 7 i zastąp ten plik w instalacji Java 6. Prawdopodobnie najlepiej najpierw zrobić kopię zapasową pliku cacerts, ale potem wystarczy skopiować nowy plik i BOOM! to po prostu działa.
Zauważ, że faktycznie skopiowałem plik Windows Cacerts do instalacji Linuksa i działał dobrze.
Plik znajduje się
jre/lib/security/cacerts
zarówno w starej, jak i nowej instalacji Java JDK.Mam nadzieję, że to ocali komuś godziny pogorszenia.
źródło
$JAVA_HOME/jre/lib
, a nie$JAVA_HOME/lib
- spędziłem trochę czasu, omijając ten szczegół.Podejście MY UI:
CMD-Line:
keytool -importcert -file jetty.crt -alias jetty -keystore $JAVA_HOME/jre/lib/security/cacerts
changeit
(Może być zmieniony na Macu)źródło
keytool -importcert -file dinardap_cert.cer –alias dinardap –keystore “%JAVA_HOME%/jre/lib/security/cacerts”
Natknąłem się na ten problem, który wymagał wielu godzin badań, zwłaszcza w przypadku automatycznie generowanych certyfikatów, które w przeciwieństwie do oficjalnych, są dość trudne i Java ich nie lubi.
Sprawdź następujący link: Rozwiąż problem z certyfikatami w Javie
Zasadniczo musisz dodać certyfikat z serwera do certyfikatów Java Home.
InstallCert
i uruchom go podczas działania serwera, podając następujące argumentyserver[:port]
. Hasło nie jest potrzebne, ponieważ oryginalne hasło działa dla certyfikatów Java („changeit”).jssecerts
plik w katalogu, w którym wykonałeś program (jeśli wykonano go z Eclipse, upewnij się, że skonfigurowałeś Work katalog wRun -> Configurations
).$JAVA_HOME/jre/lib/security
Po wykonaniu tych kroków połączenia z certyfikatem nie będą już generować wyjątków w Javie.
Poniższy kod źródłowy jest ważny i zniknął z blogów Oracle (Sun), jedyna strona, którą znalazłem, był pod podanym linkiem, dlatego dołączam go w odpowiedzi na wszelkie odniesienia.
źródło
SandeepanNath:test sandeepan.nath$ java InstallCert repo1.maven.org:443 Loading KeyStore /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/security/cacerts... Opening connection to repo1.maven.org:443 ... Starting SSL handshake... javax.net.ssl.SSLException: Received fatal alert: protocol_version .. Could not obtain server certificate chain
1. Sprawdź certyfikat
Spróbuj załadować docelowy adres URL w przeglądarce i przejrzeć certyfikat witryny (zwykle jest dostępny za pomocą ikony ze znakiem blokady. Znajduje się po lewej lub prawej stronie paska adresu przeglądarki), niezależnie od tego, czy wygasł, czy nie był z innych powodów niezaufany.
2. Zainstaluj najnowsze wersje JRE i JDK
Nowe wersje zwykle zawierają zaktualizowany zestaw zaufanych certyfikatów.
Również jeśli to możliwe, odinstaluj stare wersje. Sprawi to, że błędy w konfiguracji będą jawne.
3. Sprawdź konfigurację:
4. Skopiuj cały magazyn kluczy z nowej wersji Java
Jeśli tworzysz w JDK innym niż najnowszy dostępny - spróbuj zastąpić
%JAVA_HOME%/jre/lib/security/cacerts
plik nowym plikiem z najnowszego zainstalowanego środowiska JRE (najpierw wykonaj kopię zapasową), jak sugeruje @ jeremy-goodell w swojej odpowiedzi5. Dodaj certyfikaty do swojego magazynu kluczy
Jeśli nic powyżej nie rozwiązuje problemu, użyj
keytool
certyfikatu (ów) do magazynu kluczy Java:Plik z certyfikatem można uzyskać z przeglądarki, jak sugeruje @MagGGG w swojej odpowiedzi .
Uwaga 1: może być konieczne powtórzenie tego dla każdego certyfikatu w łańcuchu do certyfikatu witryny. Zacznij od roota.
Uwaga 2:
<alias_name>
powinna być unikalna wśród kluczy w sklepie lubkeytool
pokaże błąd.Aby uzyskać listę wszystkich certyfikatów w sklepie, możesz uruchomić:
Jeśli coś pójdzie nie tak, pomoże Ci to usunąć certyfikat ze sklepu:
źródło
Służy do przeskoczenia sprawdzania poprawności certyfikatu.
Ostrzeżenie Używanie tylko do celów programistycznych w tym celu jest niepewne!
źródło
Miałem nieco inną sytuację, gdy zarówno JDK, jak i JRE 1.8.0_112 były obecne w moim systemie.
Zaimportowałem nowe certyfikaty CA,
[JDK_FOLDER]\jre\lib\security\cacerts
używając już znanego polecenia:Nadal otrzymywałem ten sam błąd podczas budowania ścieżki PKIX .
Dodałem informacje debugowania do interfejsu CLI Java, używając
java -Djavax.net.debug=all ... > debug.log
. W pliku debug.log wiersz rozpoczynający się od trustStore to: faktycznie wskazywał na sklep cacerts znaleziony w[JRE_FOLDER]\lib\security\cacerts
.W moim przypadku rozwiązaniem było skopiowanie pliku cacerts używanego przez JDK (z dodanymi nowymi urzędami certyfikacji) na plik używany przez JRE i to rozwiązało problem.
źródło
Tło problemu:
Pojawił się następujący błąd podczas próby uruchomienia instalacji mvn clean w moim projekcie i poprzez opcję Netbeans IDE czyszczenia i kompilacji. Ten problem wynika z faktu, że certyfikat nie jest dostępny, gdy pobieramy przez NET bean IDE / przez wiersz polecenia, ale możemy pobrać pliki przez przeglądarkę.
Błąd :
Rozkład:
1. Pobierz certyfikat odnośnego adresu URL:
2. Teraz zainstaluj magazyn kluczy, aby rozwiązać problem.
Przykładowe polecenia / dane wyjściowe z wiersza poleceń:
źródło
Chciałem zaimportować certyfikat dla smtp.gmail.com
Jedynym rozwiązaniem, które działało dla mnie, jest 1. Wpisz polecenie, aby wyświetlić ten certyfikat
Skopiuj i zapisz linie między „----- ROZPOCZNIJ CERTYFIKAT -----” i „----- ZAKOŃCZ CERTYFIKAT -----” w pliku gmail.cer
Biegać
Wpisz hasło chageit
Kliknij przycisk tak, aby zaimportować certyfikat
Uruchom ponownie java
teraz uruchom polecenie i możesz już iść
źródło
To nie jest odpowiedź na Twittera, ale to pytanie pojawia się, gdy szukasz tego błędu. Jeśli system otrzymuje ten błąd podczas łączenia się z witryną, która wydaje się mieć prawidłowy certyfikat podczas przeglądania w przeglądarce internetowej , prawdopodobnie oznacza to, że witryna ma niekompletny łańcuch certyfikatów .
Krótkie podsumowanie problemu: urzędy certyfikacji nie używają swojego certyfikatu głównego do podpisywania tylko starych certyfikatów. Zamiast tego (zwykle) podpisują pośrednie certyfikaty które również mają ustawioną flagę ośrodka certyfikacji (tzn. Mogą podpisywać certyfikaty). Następnie, kupując certyfikat od urzędu certyfikacji, podpisują on raport CSR jednym z tych certyfikatów pośrednich.
Twój sklep zaufania Java najprawdopodobniej ma tylko certyfikat główny, a nie pośredni.
Błędnie skonfigurowana witryna może po prostu wrócić podpisany certyfikat. Problem: został podpisany pośrednim certyfikatem, którego nie ma w twoim magazynie zaufania. Przeglądarki poradzą sobie z tym problemem poprzez pobranie lub użycie buforowanego certyfikatu pośredniego; maksymalizuje to kompatybilność strony internetowej. Jednak Java i narzędzia takie jak OpenSSL nie będą. A to spowoduje błąd w pytaniu.
Możesz zweryfikować to podejrzenie za pomocą testu Qualys SSL . Jeśli uruchomisz to na stronie i to powie
to to potwierdza. Możesz to również zobaczyć, patrząc na ścieżki certyfikacji i tekst Extra Download .
Jak to naprawić: administrator serwera musi tak skonfigurować serwer WWW, aby zwracał również certyfikaty pośrednie. Na przykład w Comodo przydatny jest
.ca-bundle
plik. Na przykład w konfiguracji Apache z mod_ssl użyłbyśSSLCertificateChainFile
ustawienia konfiguracji. W przypadku Nginx musisz połączyć certyfikaty pośrednie i podpisany certyfikat i użyć go w konfiguracji certyfikatu SSL. Aby znaleźć więcej, wyszukaj „niekompletny łańcuch certyfikatów” online.źródło
Przyczyną powyższego błędu jest to, że JDK jest pakowany z wieloma zaufanymi certyfikatami urzędu certyfikacji (CA) w plik o nazwie „cacerts”, ale ten plik nie ma pojęcia o naszym certyfikacie z podpisem własnym. Innymi słowy, plik cacerts nie ma zaimportowanego naszego certyfikatu z podpisem własnym, a zatem nie traktuje go jako zaufanego podmiotu i dlatego powoduje powyższy błąd.
Jak naprawić powyższy błąd
Aby naprawić powyższy błąd, wystarczy zaimportować samopodpisany certyfikat do pliku cacerts.
Najpierw zlokalizuj plik cacerts. Musimy znaleźć lokalizację JDK. Jeśli uruchamiasz aplikację za pośrednictwem jednego z IDE, takich jak Eclipse lub IntelliJ Idea, przejdź do ustawień projektu i dowiedz się, jaka jest lokalizacja JDK. Na przykład w systemie Mac OS typowa lokalizacja pliku cacerts byłaby w tej lokalizacji / Library / Java / JavaVirtualMachines / {{JDK_version}} / Contents / Home / jre / lib / security na komputerze z systemem Windows, to w {{katalog_instalacyjny} } / {{JDK_version}} / jre / lib / security
Po zlokalizowaniu pliku cacerts musimy teraz zaimportować nasz samopodpisany certyfikat do tego pliku cacerts. Sprawdź ostatni artykuł, jeśli nie wiesz, jak poprawnie wygenerować samopodpisany certyfikat.
Jeśli nie masz pliku certyfikatu (.crt) i po prostu masz plik .jks, możesz wygenerować plik .crt za pomocą poniższej komendy. Jeśli masz już plik .crt / .pem, możesz zignorować poniższe polecenie
## Aby wygenerować certyfikat z magazynu kluczy (plik .jks) ####
Powyższy krok wygeneruje plik o nazwie selfsigned.crt.Now Zaimportuj certyfikat do cacerts
Teraz dodaj certyfikat do JRE / lib / security / cacerts (trustore)na przykład
To wszystko, uruchom ponownie aplikację i powinna działać poprawnie. Jeśli nadal nie działa i uzyskaj wyjątek uzgadniania SSL. Prawdopodobnie oznacza to, że używasz innej domeny niż zarejestrowana w certyfikacie.
Link ze szczegółowym wyjaśnieniem i krok po kroku znajduje się tutaj.
źródło
Dodawanie
cacerts
nie działało dla mnie. Po włączeniu dziennika z flagą-Djavax.net.debug=all
poznałem czytanie z języka Javajssecacerts
.W
jssecacerts
końcu zaimportuj .źródło
jssecacerts
jeśli jest obecna, w przeciwnym raziecacerts
.To rozwiązanie, ale w formie mojej historii z tym problemem:
Byłem prawie martwy, wypróbowując wszystkie powyższe rozwiązania (przez 3 dni) i nic nie działało dla mnie.
Straciłem wszelką nadzieję.
Skontaktowałem się z moim zespołem ds. Bezpieczeństwa w tej sprawie, ponieważ byłem za serwerem proxy i powiedzieli, że niedawno zaktualizowali swoją politykę bezpieczeństwa.
Źle ich skarciłem za to, że nie informowali programistów.
Później wydali nowy plik „cacerts”, który zawiera wszystkie certyfikaty.
Usunąłem plik cacerts, który jest obecny w% JAVA_HOME% / jre / lib / security i to rozwiązało mój problem.
Więc jeśli masz do czynienia z tym problemem, może to być również twój zespół sieciowy.
źródło
Natknąłem się na to pytanie, próbując zainstalować wtyczkę Cucumber-Eclipse w Eclipse za pośrednictwem witryny aktualizacji. Otrzymałem ten sam błąd SunCertPathBuilderException:
Chociaż niektóre z pozostałych odpowiedzi są odpowiednie i pomocne w danej sytuacji tego pytania, były jednak nieprzydatne i mylące dla mojego problemu.
W moim przypadku problemem było to, że adres URL podany dla ich witryny aktualizacji to:
Jednak podczas nawigowania do niego za pomocą przeglądarki przekierowano do (zwróć uwagę na dodane „ .github ”):
Dlatego rozwiązaniem jest po prostu użycie przekierowanej wersji adresu URL witryny aktualizacji podczas dodawania witryny aktualizacji w środowisku eclipse.
źródło
Napotkałem ten sam problem i rozwiązałem go, wykonując poniższe proste kroki:
1) Pobierz InstallCert.java z Google
2) Skompiluj za pomocą javac InstallCert.java
3) Uruchom InstallCert.java, używając java InstallCert.java , z nazwą hosta i portem https, i naciśnij „1”, gdy poprosisz o wprowadzenie danych. Dodanie „localhost” jako zaufanego magazynu kluczy i wygenerowanie pliku o nazwie „jssecacerts”, jak poniżej:
java InstallCert localhost: 443
4) skopiuj plik jssecacerts do folderu $ JAVA_HOME / jre / lib / security
Główne źródło rozwiązania problemu tutaj:
https://ankurjain26.blogspot.in/2017/11/javaxnetsslsslhandshakeexception.html
źródło
Rozwiązałem ten problem w systemie Windows Server 2016 z Javą 8, importując cert ze
pkcs12
sklepu docacerts
magazynu kluczy.Ścieżka do sklepu pkcs12:
C:\Apps\pkcs12.pfx
Ścieżka do cacerts Java:
C:\Program Files\Java\jre1.8.0_151\lib\security\cacerts
Ścieżka do keytool:
C:\Program Files\Java\jre1.8.0_151\bin
Po umieszczeniu w folderze z keytool w wierszu polecenia (jako administrator) polecenie importowania certyfikatu z
pkcs12
docacerts
jest następujące:keytool -v -importkeystore -srckeystore C:\Apps\pkcs12.pfx -srcstoretype PKCS12 -destkeystore "C:\Program Files\Java\jre1.8.0_151\lib\security\cacerts" -deststoretype JKS
Zostaniesz poproszony o:
1. wprowadzenie docelowego hasła do pliku kluczy (hasło cacerts, domyślnie „changeit”)
2. wprowadź hasło źródłowego pliku kluczy (hasło pkcs12)
Aby zmiany odniosły skutek, zrestartuj serwer (lub ponownie uruchom JVM).
źródło
Tutaj zwykle ten rodzaj wyjątku występuje, gdy występuje niezgodność w ścieżce PATH zaufanego certyfikatu. Sprawdź konfigurację lub ścieżkę, w której ten certyfikat serwera jest wymagany do bezpiecznej komunikacji.
źródło
Dla mnie pojawił się błąd certyfikatu, ponieważ miałem skrzypek działający w tle, co popsuło się certyfikatem. Działa jak proxy tak blisko, że ponownie uruchamia zaćmienie.
źródło
cele:
Jak to zrobić:
Plik otoki mojego magazynu kluczy:
Ta klasa utworzy magazyn kluczy, jeśli to konieczne, i będzie w stanie zarządzać wewnątrz nim certyfikatami. Teraz klasa dla kontekstu SSL:
Ta klasa została utworzona jako singleton, ponieważ dozwolony jest tylko jeden domyślny kontekst SSL. Więc teraz użycie:
Być może nie będzie działać z tymi ustawieniami, ponieważ przechowuję plik certyfikatu w folderze zasobów, więc moja ścieżka nie jest bezwzględna. Ale ogólnie działa idealnie.
źródło
available()
jest wyraźnie przestrzegane w jej własnym Javadoc.Jest to dodatek do odpowiedzi https://stackoverflow.com/a/36427118/1491414 . Dzięki @MagGGG
źródło
Naprawiłem to za pomocą poniższej metody-
źródło
Gdy masz powyżej błąd związany z oprogramowaniem atlassian np. Jira
możesz dodać certyfikaty do zaufanego magazynu kluczy (zmień brakujący_ca na prawidłową nazwę certyfikatu):
Jeśli zostaniesz poproszony o podanie hasła, wpisz
changeit
i potwierdźy
Następnie po prostu uruchom ponownie Jira.
źródło
Jeśli adres URL repozytorium działa również na HTTP, a bezpieczeństwo nie stanowi problemu, możesz przejść do settings.xml (często, ale nie zawsze, znajduje się w
%USERPROFILE%/.m2
) i zastąpić HTTPS HTTP dla<repository>
i<pluginRepository>
adresów URL.Na przykład:
należy zastąpić następującym:
źródło
Korzystałem z własnego magazynu zaufania zamiast JRE, przekazując arg
-Djavax.net.ssl.trustStore=
Ten błąd pojawiał się niezależnie od certyfikatów w magazynie zaufanych certyfikatów. Problemem było dla mnie uporządkowanie właściwości przekazywanych na linii arg. Kiedy wstawiłem
-Djavax.net.ssl.trustStore=
&-Djavax.net.ssl.trustStorePassword=
before-Dspring.config.location=
&-jar
args, udało mi się pomyślnie wywołać moje połączenie przez https.źródło
Jeśli używasz CloudFoundry i napotkasz problem z certyfikatem, musisz upewnić się, że ponownie wcisnąłeś słoik za pomocą usługi magazynu kluczy z certyfikatem. Po prostu cofnij powiązanie, powiązanie i ponowne uruchomienie nie będzie działać.
źródło
Jeśli Twój host znajduje się za zaporą / proxy , użyj następującego polecenia w cmd:
Wymień
<proxy_hostname>
i<proxy_port>
z serwera proxy HTTP, który jest skonfigurowany. Zamień na<remote_host_name:remote_ssl_port>
jeden z hostów zdalnych (w zasadzie url) i port z problemem certyfikacji.Weź ostatnią wydrukowaną treść certyfikatu i skopiuj ją (również skopiuj certyfikat początkowy i końcowy). Wklej go do pliku tekstowego i nadaj mu rozszerzenie .crt . Teraz zaimportuj ten certyfikat do cacerts za pomocą komendy java keytool i powinien on działać.
źródło
Spróbuj skopiować cacerts Java:
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.172-9.b11.fc28.x86_64/jre/lib/security/cacerts $JAVA_HOME/jre/lib/security/cacerts
źródło
Jeśli ten problem występuje w kontenerze linux, gdy aplikacja Java próbuje komunikować się z inną aplikacją / witryną, to dlatego, że certyfikat został niepoprawnie zaimportowany do modułu równoważenia obciążenia. Aby zaimportować certyfikaty, należy wykonać sekwencję kroków, a jeśli nie zostaną wykonane poprawnie, pojawią się takie problemy
Po prawidłowym zaimportowaniu certyfikatów należy to zrobić. Nie trzeba majstrować przy jakichkolwiek certyfikatach JDK.
źródło
Rozwiązałem go dla Intellij Idea Stoję przed tym problemem Althouh, zmieniam wiele miejsc, aby rozwiązać problem. Znalazłem rozwiązanie dla mnie. Kliknij prawym przyciskiem myszy swój projekt, zobaczysz Maven , po tym naciśnij Generuj źródła i aktualizuj foldery i ponownie importuj
Zrobione.
źródło
Napotkałem ten sam problem, korzystałem z wersji 8.1.0-3, ale później użyłem wersji 9.2.1-0 i problem został rozwiązany bez żadnych ręcznych kroków. Samopodpisany certyfikat działał dobrze.
źródło