Problemy z używaniem Mavena i SSL za proxy

133

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 httpi httpsdostępu przez settings.xmlplik. 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
Andy
źródło
2
Rozwiązałem to zgodnie z odpowiedzią rec, aby zignorować sprawdzanie certyfikatu SSL.
Evin1_

Odpowiedzi:

182

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ę.

    <settings>
  <activeProfiles>
    <!--make the profile active all the time -->
    <activeProfile>securecentral</activeProfile>
  </activeProfiles>
  <profiles>
    <profile>
      <id>securecentral</id>
      <!--Override the repository (and pluginRepository) "central" from the
         Maven Super POM -->
      <repositories>
        <repository>
          <id>central</id>
          <url>http://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>http://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
</settings>

Możesz alternatywnie użyć prostego repozytorium http maven w ten sposób

 <pluginRepositories>
    <pluginRepository>
      <id>central</id>
      <name>Maven Plugin Repository</name>
      <url>http://repo1.maven.org/maven2</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
      <releases>
        <updatePolicy>never</updatePolicy>
      </releases>
    </pluginRepository>
  </pluginRepositories>

Daj mi znać, jeśli moje rozwiązanie działa;)

JOT.

biology.info
źródło
2
Dzięki za szybką i dokładną odpowiedź, zadziałało i prawdopodobnie pomoże wielu osobom, które zaczną używać maven po sierpniu 2014 :-) W międzyczasie dowiedziałem się, jak sprawić, by działał z SSL. Opublikuję to jako odpowiedź poniżej, aby pomóc innym, ale Twoja odpowiedź będzie oficjalnie zaakceptowana. Dzięki
Andy
Dziękuję Andy;) Oba rozwiązania działają u Ciebie? czy tylko alternatywa?
biology.info
4
Tak, próbowałem i działa. Jednak w pierwszym bloku kodu musiałem zmienić adresy URL obu repozytoriów z https na http, w przeciwnym razie otrzymałem ten sam komunikat o błędzie co poprzednio. Ponadto każdy, kto to próbuje, nie zapomina o tagu <activeProfiles>.
Andy
1
Właśnie spróbowałem z drugim alternatywnym prostym rozwiązaniem, zadziałało dla mnie ... Dzięki.
Blue Diamond
7
Od 15 stycznia 2020 r. Centralne repozytorium nie obsługuje już niezabezpieczonej komunikacji za pośrednictwem zwykłego protokołu HTTP i wymaga, aby wszystkie żądania do repozytorium były szyfrowane za pośrednictwem protokołu HTTPS.
Ahmad Alkhatib
183

Powyższa odpowiedź jest dobrym działającym rozwiązaniem, ale oto jak to zrobić, jeśli chcesz korzystać z repozytorium SSL:

  • Użyj przeglądarki (użyłem IE), aby przejść do https://repo.maven.apache.org/
    • Kliknij ikonę kłódki i wybierz „Wyświetl certyfikat”
    • Przejdź do zakładki „Szczegóły” i wybierz „Zapisz do pliku”
    • Wybierz typ „Base 64 X.509 (.CER)” i zapisz go gdzieś
  • 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_OPTSzmiennej środowiskowej, więc nie musisz się tym więcej martwić. Zobacz więcej informacji na temat MAVEN_OPTSzmiennej tutaj :

Andy
źródło
15
Należy to zaakceptować jako poprawną odpowiedź. Twój serwer proxy ISA wstawia certyfikat pośredni, który nie jest zaufany przez JDK.
Gordon,
2
Mam Mavena działającego z wiersza poleceń. Jak sprawić, by działał podczas zaćmienia?
Prabodh Mhalgi
Łatwe wycinanie i wklejanie dla MAVEN_OPTS: -Xmx512m -Djavax.net.ssl.trustStore = trust.jks -Djavax.net.ssl.trustStorePassword = -Djavax.net.ssl.keyStore = / home / directory / mycertificate.p12 - Djavax.net.ssl.keyStoreType = pkcs12 -Djavax.net.ssl.keyStorePassword = XXXXXX
Al Lelopath
To rozwiązało mój problem. Gdy prosi o hasło do magazynu kluczy, domyślnie jest to „zmień”, jeśli jeszcze go nie zmieniłeś. :)
John Manko
3
Ponadto w systemie Ubuntu możesz uruchomić polecenie takie jaksudo keytool -import -file ./repo.maven.apache.org.crt -keystore /usr/lib/jvm/java-8-oracle/jre/lib/security/cacerts
John Manko
23

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:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

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):

sudo keytool -delete -alias mój klucz -keystore / etc / ssl / certs / java / cacerts

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:

/ etc / ssl / certs / java / cacerts

Możesz zobaczyć, jakie certyfikaty się tam znajdują, uruchamiając to polecenie:

keytool -list -keystore / etc / ssl / certs / java / cacerts

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ć:

sudo keytool -import -file DigiCertGlobalRootCA.crt -keystore / etc / ssl / certs / java / cacerts

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:

mykey, 2 grudnia 2015 r., trustCertEntry, odcisk cyfrowy certyfikatu (SHA1): A8: 98: 5D: 3A: 65: E5: E5: C4: B2: D7: D6: 6D: 40: C6: DD: 2F: B1: 9C : 54: 36

Wtedy mogłem normalnie uruchamiać polecenia mvn, bez potrzeby określania magazynu kluczy.

Łukasz
źródło
Dzięki Andy. Oraz Leelanda, który ponownie opublikował swój blog. nodsw.com/blog/leeland/2006/12/… I tobie też, @Luke.
ajoshi
13

Możesz skorzystać z -Dmaven.wagon.http.ssl.insecure=trueopcji

dieter
źródło
11

Możesz zaimportować certyfikat SSL ręcznie i po prostu dodać go do magazynu kluczy.

Dla użytkowników Linuksa,

Składnia:

keytool -trustcacerts -keystore / jre / lib / security / cacerts -storepass changeit -importcert -alias nexus -file

Przykład:

keytool -trustcacerts -keystore /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/security/cacerts -storepass changeit -importcert -alias nexus -file ~ / Downloads / abc.com-ssl. crt

Balaji Boggaram Ramanarayan
źródło
Na początku nadal musisz zapisać certyfikat zgodnie z opisem w odpowiedzi Andy'ego . Więc rozszerzenie to „.cer”.
sjngm
9

To może nie być najlepsze rozwiązanie. Zmieniłem mavena z 3.3.x na 3.2.x. I ten problem zniknął.

Senthil
źródło
Próbowałem zainstalować certyfikaty przez kilka godzin bez powodzenia i to rozwiązanie w końcu zadziałało! Najnowsza wersja mavena, którą dostałem do pracy, to 3.2.2.
jlars62
3.3.3 i 3.2.5 nie działały dla mnie, ale 3.0.5 działało
ROMANIA_engineer
Wylądowałem tutaj z wyszukiwarki, ale używam Gradle zamiast Maven. Aktualizacja mojej starszej wersji Gradle również rozwiązała te dziwne problemy z SSL.
Nik Reiman
6

Właściwie miałem ten sam problem.

kiedy biegam

czysty pakiet mvn

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:

keytool -list -keystore "ścieżka Java +" / jre / lib / security / cacerts ""

na przykład w moim przypadku jest to:

keytool -list -keystore / usr / lib / jvm / jdk-8-oracle-arm32-vfp-hflt / jre / lib / security / cacerts

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:

sudo keytool -importcert -file /home/hal/Public/certificate_file_downloaded.cer -keystore / usr / lib / jvm / jdk-8-oracle-arm32-vfp-hflt / jre / security / cacerts

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

keytool -list -keystore / usr / lib / jvm / jdk-8-oracle-arm32-vfp-hflt / jre / lib / security / cacerts

po raz kolejny w moim przypadku uzyskałem 94 zawartość pliku cacerts

to znaczy, że został pomyślnie dodany.

halim
źródło
2

Szybkim rozwiązaniem jest dodanie tego kodu w swoim pom.xml:

<repositories>
    <repository>
        <id>central</id>
        <name>Maven Plugin Repository</name>
        <url>http://repo1.maven.org/maven2</url>
        <layout>default</layout>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
        <releases>
            <updatePolicy>never</updatePolicy>
        </releases>
    </repository>
</repositories>

Gdzie nigdy nie jest dla uniknięcia wyszukiwania certyfikowany.

jcarlosp1986
źródło
1
Warto przewinąć wątek odpowiedzi w dół. To działało po prostu!
srebrny
1

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%\bindo 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.

Gene M.
źródło
1

Krok 1: POBIERZ zawartość certyfikatu strony internetowej (chcesz, aby została zaimportowana jako zaufany katalog główny)

$ keytool -printcert -rfc -sslserver maven.2xoffice.com*

-----BEGIN CERTIFICATE-----
MIIFNTCCBB2gAwIBAgIHJ73QrVnyJjANBgkqhkiG9w0BAQsFADCBtDELMAkGA1UEBhMCVVMxEDAO
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVMxITAfBgNVBAoT
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY
...
-----END CERTIFICATE-----
The -rfc option outputs the certificate chain in PEM-encoded format for easy import back into a keystore.

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)

$ keytool -importcert -file ./godaddyg2.pem -keystore $JRE_LIB/lib/security/cacerts
vks
źródło
1

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.)

  <!-- proxies
   | This is a list of proxies which can be used on this machine to connect to the network.
   | Unless otherwise specified (by system property or command-line switch), the first proxy
   | specification in this list marked as active will be used.
   |-->
  <proxies>
    <!-- proxy
     | Specification for one proxy, to be used in connecting to the network.
     |
    <proxy>
      <id>optional</id>
      <active>true</active>
      <protocol>http</protocol>
      <username>proxyuser</username>
      <password>proxypass</password>
      <host>proxy.host.net</host>
      <port>80</port>
      <nonProxyHosts>local.net|some.host.com</nonProxyHosts>
    </proxy>
    -->

    <proxy>
      <id>my-proxy</id>
      <active>true</active>
      <protocol>http</protocol>
      <username></username>
      <password></password>
      <host>my.proxy.host.com</host>
      <port>8080</port>
      <nonProxyHosts></nonProxyHosts>
    </proxy>

  </proxies>

Następnie wskaż, pom.xmlaby pobrać z centralnego repozytorium http maven:

<project>
...
    <repositories>
        <repository>
            <id>central</id>
            <name>Maven Plugin Repository</name>
            <url>http://repo1.maven.org/maven2</url>
            <layout>default</layout>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
            <releases>
                <updatePolicy>never</updatePolicy>
            </releases>
        </repository>
    </repositories>
...
</project>

Konieczne może być również skonfigurowanie serwera proxy http w swoim IDE. Dla VSCode w settings.json:

{
    ...
    "http.proxy": "http://my/proxy/script/address/my-proxy.pac",
    ...
}

W przypadku Win10: Start / Wyszukaj> Ustawienia proxy sieci> Adres skryptu wprowadź opis obrazu tutaj

Źródła:

srebro
źródło
0

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).

apokalipsa
źródło
0

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 !!!

Tudor
źródło
0

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::

  1. Przełącz się na wcześniejszą wersję jdk (która miała już zainstalowany certyfikat) dla nowego projektu i wykonaj czystą instalację
  2. Pobierz ponownie certyfikat dla nowej wersji jdk, na którą niedawno się przełączyłeś, a następnie przeprowadź czystą instalację
mitesh keswani
źródło
0

Po utworzeniu magazynu kluczy wspomnianego przez @Andy. W Eclipse dodałem argumenty jvm i zadziałało.

wprowadź opis obrazu tutaj

wprowadź opis obrazu tutaj

Tim
źródło
0

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

Pokos
źródło
-1

Jeszcze jedna przyczyna: jeśli otworzysz Charlesa, możesz również napotkać ten problem, w tym przypadku po prostu rzuć Charlesa.

zhuguowei
źródło
-1

Po prostu użyłem nowej wersji Java i zadziałało.

zestaw
źródło