Właśnie pobrałem Mavena i próbowałem uruchomić proste polecenie znalezione na stronie „Maven w pięć minut” ( http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html ). To jest polecenie:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
Po uruchomieniu otrzymuję błąd z certyfikatem SSL i nie mogę pobrać z centralnego repozytorium Maven pod adresem https://repo.maven.apache.org/maven2 . Błąd to „SunCertPathBuilderException: nie można znaleźć prawidłowej ścieżki certyfikacji do żądanego celu”.
Siedzę za firmową zaporą sieciową i poprawnie skonfigurowałem ustawienia proxy dla obu http
i https
dostępu przez settings.xml
plik. Wątpię, czy każdy, kto pobiera Mavena i uruchamia go po raz pierwszy, musi importować certyfikat SSL repozytorium Mavena, więc problem musi być z proxy. Czy ktoś ma z tym jakieś doświadczenie?
Oto ślad stosu w trybie pełnego debugowania (-X):
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
Maven home: C:\Projects\maven\bin\..
Java version: 1.7.0_45, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_45\jre
Default locale: it_IT, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
[DEBUG] Using connector WagonRepositoryConnector with priority 0.0 for https://repo.maven.apache.org/maven2 via *****:8080 with username=*****, password=***
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-clean-plugin:2.5: Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-clean-plugin:jar:2.5
org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-clean-plugin:jar:2.5
at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:122)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:148)
at org.apache.maven.plugin.DefaultBuildPluginManager.loadPlugin(DefaultBuildPluginManager.java:81)
at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolveFromProject(DefaultPluginPrefixResolver.java:138)
at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolveFromProject(DefaultPluginPrefixResolver.java:121)
at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolve(DefaultPluginPrefixResolver.java:85)
at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.findPluginForPrefix(MojoDescriptorCreator.java:260)
at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:220)
at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:103)
at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:83)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:85)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-clean-plugin:jar:2.5
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:349)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:231)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:288)
at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:108)
... 23 more
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.5 from/to central (https://repo.maven.apache.org/maven2): sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:459)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:262)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:239)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:334)
... 26 more
Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.5 from/to central (https://repo.maven.apache.org/maven2): sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$6.wrap(WagonRepositoryConnector.java:1016)
at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$6.wrap(WagonRepositoryConnector.java:1004)
at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:725)
at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.apache.maven.wagon.TransferFailedException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:935)
at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:660)
... 4 more
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(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1884)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1341)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at org.apache.maven.wagon.providers.http.httpclient.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:280)
at org.apache.maven.wagon.providers.http.httpclient.impl.conn.HttpClientConnectionOperator.upgrade(HttpClientConnectionOperator.java:167)
at org.apache.maven.wagon.providers.http.httpclient.impl.conn.PoolingHttpClientConnectionManager.upgrade(PoolingHttpClientConnectionManager.java:329)
at org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:392)
at org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute(MainClientExec.java:218)
at org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194)
at org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute(RetryExec.java:85)
at org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
at org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:756)
at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:854)
... 8 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(PKIXValidator.java:385)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1323)
... 27 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
... 33 more
Odpowiedzi:
Faktem jest, że twoja wtyczka maven próbuje połączyć się ze zdalnym repozytorium https
(np. Https://repo.maven.apache.org/maven2/ )
To jest nowa łączność SSL dla Maven Central została udostępniona w sierpniu 2014!
Więc proszę, czy możesz sprawdzić, czy twój settings.xml ma poprawną konfigurację.
Możesz alternatywnie użyć prostego repozytorium http maven w ten sposób
Daj mi znać, jeśli moje rozwiązanie działa;)
JOT.
źródło
Powyższa odpowiedź jest dobrym działającym rozwiązaniem, ale oto jak to zrobić, jeśli chcesz korzystać z repozytorium SSL:
Teraz otwórz wiersz polecenia i wpisz (użyj własnych ścieżek):
keytool -import -file C:\temp\mavenCert.cer -keystore C:\temp\mavenKeystore
Teraz możesz ponownie uruchomić polecenie z parametrem
-Djavax.net.ssl.trustStore=C:\temp\mavenKeystore
Pod linuxem użyj ścieżki bezwzględnej
-Djavax.net.ssl.trustStore=/tmp/mavenKeystore
w przeciwnym razie tak się stanie
Lubię to:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false -Djavax.net.ssl.trustStore=C:\temp\mavenKeystore
Opcjonalny:
Możesz użyć
MAVEN_OPTS
zmiennej środowiskowej, więc nie musisz się tym więcej martwić. Zobacz więcej informacji na tematMAVEN_OPTS
zmiennej tutaj :źródło
sudo keytool -import -file ./repo.maven.apache.org.crt -keystore /usr/lib/jvm/java-8-oracle/jre/lib/security/cacerts
Aktualizacja
Właśnie natknąłem się na ten raport o błędzie:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760
Wydaje się, że jest to przyczyną naszych problemów. Coś, w którym ca-Certificates-java napotkał błąd i nie wypełniło w pełni cacerts. U mnie zaczęło się to dziać po aktualizacji do 15.10 i ten błąd prawdopodobnie wystąpił podczas tego procesu.
Sposób obejścia problemu polega na wykonaniu następującego polecenia:
Jeśli sprawdzisz zawartość magazynu kluczy (tak jak w mojej pierwotnej odpowiedzi), zobaczysz teraz o wiele więcej, w tym potrzebny DigiCert Global Root CA.
Jeśli przeszedłeś przez proces w mojej oryginalnej odpowiedzi, możesz wyczyścić klucz, który dodaliśmy, uruchamiając to polecenie (zakładając, że nie określiłeś innego aliasu):
Maven będzie teraz działał dobrze.
Oryginalna odpowiedź
Chciałbym tylko rozwinąć odpowiedź Andy'ego dotyczącą dodawania certyfikatu i określania magazynu kluczy. To sprawiło, że zacząłem i w połączeniu z informacjami w innym miejscu byłem w stanie zrozumieć problem i znaleźć inne (lepsze?) Rozwiązanie.
Odpowiedź Andy'ego określa konkretnie nowy magazyn kluczy z certyfikatem Maven. Tutaj przejdę nieco szerzej i dodam certyfikat główny do domyślnego magazynu zaufanych certyfikatów java. To pozwala mi używać mvn (i innych rzeczy java) bez określania magazynu kluczy.
Dla porównania, mój system operacyjny to Ubuntu 15.10 z Maven 3.3.3.
Zasadniczo domyślny magazyn zaufanych certyfikatów java w tej konfiguracji nie ufa certyfikatowi głównemu repozytorium Maven (DigiCert Global Root CA), dlatego należy go dodać.
Znalazłem go tutaj i pobrałem:
https://www.digicert.com/digicert-root-certificates.htm
Następnie znalazłem domyślną lokalizację truststore, która znajduje się tutaj:
Możesz zobaczyć, jakie certyfikaty się tam znajdują, uruchamiając to polecenie:
Po wyświetleniu monitu domyślne hasło magazynu kluczy to „changeit” (ale nikt nigdy tego nie robi).
W mojej konfiguracji odcisk palca „DigiCert Global Root CA” nie istniał (DigiCert nazywa go „odcisk palca” w powyższym łączu). Oto jak to dodać:
Powinno to spowodować, że jeśli ufasz certyfikatowi, powiedz tak.
Użyj ponownie keytool -list, aby sprawdzić, czy klucz istnieje. Nie zawracałem sobie głowy określaniem aliasu (-alias), więc skończyło się tak:
Wtedy mogłem normalnie uruchamiać polecenia mvn, bez potrzeby określania magazynu kluczy.
źródło
Możesz skorzystać z
-Dmaven.wagon.http.ssl.insecure=true
opcjiźródło
Możesz zaimportować certyfikat SSL ręcznie i po prostu dodać go do magazynu kluczy.
Dla użytkowników Linuksa,
Składnia:
Przykład:
źródło
To może nie być najlepsze rozwiązanie. Zmieniłem mavena z 3.3.x na 3.2.x. I ten problem zniknął.
źródło
Właściwie miałem ten sam problem.
kiedy biegam
w moim projekcie maven otrzymuję ten błąd certyfikatu przez narzędzie maven.
Śledziłem odpowiedź @Andy do momentu, w którym pobrałem plik .cer
potem reszta odpowiedzi nie zadziałała dla mnie, ale zrobiłem następujące (pracuję na maszynie Linux Debian)
przede wszystkim uruchom:
na przykład w moim przypadku jest to:
jeśli zapyta o hasło, po prostu naciśnij enter.
to polecenie ma na celu wyświetlenie wszystkich certyfikatów ssl akceptowanych przez java. wykonując to polecenie w moim przypadku mam np. 93 certyfikaty.
Teraz dodaj pobrany plik .cer do pliku cacerts , uruchamiając następujące polecenie:
wpisz swoje hasło sudo, a następnie zapyta Cię o hasło do magazynu kluczy
domyślnym jest changeit
potem powiedzieć y , że ufasz temu świadectwo.
jeśli uruchomisz polecenie
po raz kolejny w moim przypadku uzyskałem 94 zawartość pliku cacerts
to znaczy, że został pomyślnie dodany.
źródło
Szybkim rozwiązaniem jest dodanie tego kodu w swoim pom.xml:
Gdzie nigdy nie jest dla uniknięcia wyszukiwania certyfikowany.
źródło
Otrzymałem ten sam błąd dotyczący certyfikatu SSL, gdy Maven próbował automatycznie pobrać niezbędne moduły.
Jako środek zaradczy próbowałem zaimplementować powyższą odpowiedź Łukasza, ale okazało się, że certyfikat DigiCert Global Root CA jest już w zaufanym magazynie kluczy Java.
Pomogło mi dodanie
%JAVA_HOME%\bin
do zmiennej Path (używam systemu Windows). I%JAVA_HOME%
jest to lokalizacja JDK, a nie tylko lokalizacja JRE, ponieważ Maven potrzebuje JDK.Nie jestem pewien, dlaczego to pomogło, ale pomogło. Jestem absolutnie pewien, że to była jedyna rzecz, jaką zmieniłem.
źródło
Jeśli ten problem wystąpi w repozytorium HTTPS , np. Https://repo.spring.io/milestone , możesz po prostu spróbować zastąpić go niezabezpieczonym: http://repo.spring.io/milestone . I to wszystko
źródło
Krok 1: POBIERZ zawartość certyfikatu strony internetowej (chcesz, aby została zaimportowana jako zaufany katalog główny)
Krok 2: Zapisz całość (w tym wiersze BEGIN CERTIFICATE i END CERTIFICATE, które są istotne w tym przypadku) jako godaddyg2.pem i zaimportuj do mojego magazynu zaufania za pośrednictwem:
Krok 3: Zaimportuj certyfikat z magazynu kluczy (zaufany magazyn kluczy Java)
źródło
Co mi pomogło:
Skonfiguruj
<proxy>
ustawienia w${MAVEN_HOME}/conf/settings.xml
:(Uwaga: w przypadku innych działało, gdy skonfigurowali
${user.home}/.m2/settings.xml
. Jeśli nie ma pliku settings.xml w user.home, po prostu skopiuj go z conf / w katalogu maven.)Następnie wskaż,
pom.xml
aby pobrać z centralnego repozytorium http maven:Konieczne może być również skonfigurowanie serwera proxy http w swoim IDE. Dla VSCode w
settings.json
:W przypadku Win10: Start / Wyszukaj> Ustawienia proxy sieci> Adres skryptu
Źródła:
źródło
Natknąłem się na ten problem w tej samej sytuacji i napisałem szczegółową odpowiedź na powiązane pytanie dotyczące przepełnienia stosu, wyjaśniając, jak łatwiej zmodyfikować cacerts systemu za pomocą narzędzia GUI. Myślę, że jest to trochę lepsze niż używanie jednorazowego magazynu kluczy dla konkretnego projektu lub modyfikowanie ustawień mavena (co może powodować problemy w przyszłości).
źródło
Mimo że umieszczałem certyfikaty w cacerts, nadal otrzymywałem błąd. Okazuje się, że wstawiałem je w jre, a nie w jdk / jre.
Są dwa magazyny kluczy, pamiętaj o tym !!!
źródło
Problem, który otrzymałem, jest taki, że wcześniej używałem jdk 1.8.0_31 z zainstalowanym certyfikatem. Przerzuciłem się na jdk 1.8.0_191 ale nie zainstalowałem certyfikatu.
Ale moje projekty działały dobrze, zdałem sobie sprawę, że ich zależności zostały już pobrane. Więc kompilowali i pakowali tylko te projekty. Ale to nie zadziałało w przypadku nowych projektów maven, ponieważ ich zależności nie zostały pobrane wcześniej.
Rozwiązanie::
źródło
Po utworzeniu magazynu kluczy wspomnianego przez @Andy. W Eclipse dodałem argumenty jvm i zadziałało.
źródło
Miałem ten sam problem z SSL i Maven. Polityka informatyczna mojej firmy ogranicza mnie do wprowadzania jakichkolwiek zmian w konfiguracji komputerów, więc skopiowałem cały plik .m2 z innego komputera i wkleiłem go do folderu .m2 i zadziałało.
Folder .m2 zwykle znajduje się w katalogu c \ user \ admin
źródło
Jeszcze jedna przyczyna: jeśli otworzysz Charlesa, możesz również napotkać ten problem, w tym przypadku po prostu rzuć Charlesa.
źródło
Po prostu użyłem nowej wersji Java i zadziałało.
źródło