Remote host closed connection during handshake: SSL peer shut down incorrectly maven

I have the following error after debugging a maven download from nexus in jenkins.

Openssl works ok and the cert is a valid one issued by Amazon.

BasicRepositoryConnector-nexus.pmc.pearsonprd.tech-2-0, handling exception: javax.net.ssl.SSLException: SSL peer shut down incorrectly 09:42:35 %% Invalidated: [Session-2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] 09:42:35 BasicRepositoryConnector-nexus.tech-2-0, SEND TLSv1.2 ALERT: fatal, description = unexpected_message 09:42:35 BasicRepositoryConnector-nexus.tech-2-0, WRITE: TLSv1.2 Alert, length = 26 09:42:35 BasicRepositoryConnector-nexus.tech-2-0, called closeSocket() 09:42:35 BasicRepositoryConnector-nexus.tech-2-0, called close() 09:42:35 BasicRepositoryConnector-nexus.tech-2-0, called closeInternal(true) 09:42:35

Maven failed with the following error.

09:42:35 [ERROR] Failed to execute goal on project hybris-package: Could not resolve dependencies for project com.sap:hybris-package:jar:1.0-SNAPSHOT: Could not transfer artifact com.sap.hybris:hybris-commerce-suite:zip:6.6.0.1 from/to thirdparty (https://nexus.tech/nexus/content/repositories/thirdparty): GET request of: com/sap/hybris/hybris-commerce-suite/6.6.0.1/hybris-commerce-suite-6.6.0.1.zip from thirdparty failed: SSL peer shut down incorrectly -> [Help 1]

My thought process is that its something to do with networking or Java related? Have you seen this before?

asked May 14, 2018 at 10:58

1

Add the following to your mvn command:

-Dhttps.protocols=TLSv1.2

answered Feb 26, 2019 at 14:09

jtsnrjtsnr

1,12011 silver badges17 bronze badges

1

I am receiving the same error when connected to my employer's VPN although I don't think it's traffic volume related, but rather an issue with TLS renegotiation where a TLS client is supposed to downgrade from TLS1.3 to TLS1.2 if both parties cannot agree on TLS1.3 terms. I suspect it has something to do with our company's firewall configuration. Regardless, as listed above, adding -Dhttps.protocols=TLSv1.2 fixes the problem when running mvn from the command line, e.g.

$ mvn -Dhttps.protocols=TLSv1.2 package

If you are executing maven through Eclipse, you can add this property as a parameter in the relevant maven run configuration.

answered Oct 4, 2021 at 18:10

beaudetbeaudet

81610 silver badges12 bronze badges

This frequently happens to me at college where many devices access the maven servers at the same time. So many students are trying to access the dependencies, that the maven servers flag our IP-Addresses as a DOS attack and therefore refuse the connection.

Normally after about 10 Minutes the flag has lifted, and you can access the dependencies again.

If you need the dependencies urgently, try switching your public IP Address (e.g. phone hotspot).

Another long-term solution would be to introduce an artifact store to the network which caches and distributes the dependencies locally and only downloads unknown versions or packages from the maven servers. Talk to your local system administrator about it.

If you are using docker containers in build pipelines then you will need an artifact store, otherwise builds will fail regularly bc of the DOS flag.

answered Jun 22, 2021 at 8:53

The maven script internally makes Management API call to deploy the API Proxies. The ciphers and SSL Protocols for endpoint api.enterprise.apigee.com have been recently updated to support only TLSv1.1 and TLSv1.2. If we use any protocols other than these two protocols, then we will get the SSL Handshake Exception.

This was updated in the https://status.apigee.com in the section "Apigee Edge Scheduled Release - Monday October 30, 2017 - Starting 9:00 PM PDT - Updating SSL Protocol to api.enterprise.apigee.com".

Since maven script uses Java internally, passed the property "-Dhttps.protocols=TLSv1.2" to the maven command as follows:

mvn install -Dhttps.protocols=TLSv1.2 -Pprd-Dusername={username}-Dpassword={password} clean

With this, the maven scripts were able to run and deploy the API Proxies successfully.