Caused by: Received fatal alert: protocol_version for on Linux

(Costin caraivan) #1

Since a few days we keep getting

Caused by: Received fatal alert: protocol_version

when trying to download dependencies from Maven Central.

I assume it’s in connection to

Our configuration is:

Gradle 3.2

Build time:   2016-11-14 12:32:59 UTC
Revision:     5d11ba7bc3d79aa2fbe7c30a022766f4532bbe0f

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.7.0_80 (Oracle Corporation 24.80-b11)
OS:           Linux 4.4.0-87-generic amd64

However I’ve reproduced this with Gradle 4.0 and 4.8. In any case, we can’t really upgrade now from Gradle 3.2, this is a maintenance project. In a similar note, migrating from Java 7 is also not a valid option. Also, unfortunately this only happens on Linux.

I’ve tried various configuration options for Gradle, for example:

./gradlew build -Dhttps.protocols=TLSv1.2

./gradlew -Dhttps.protocols=TLSv1.2 build

export GRADLE_OPTS=-Dhttps.protocols=TLSv1.2 and then ./gradlew build

No luck, same error. Gradle seems to be ignoring the property, I don’t see it when running with --info.

Are we the only ones having problems connecting to Maven Central with Gradle? I haven’t found anyone else having the same issue :frowning:

Also, I can’t find documentation for this, maybe I’m passing the parameter badly? What’s the recommended way to pass HTTPS protocol parameters to Gradle?

Thank you for your time :slight_smile:

(Louis Jacomet) #2


The property https.protocols is not handled by Apache HttpClient which is what Gradle uses under the hood.
So the only workaround available for you is to configure a maven repository with the HTTP only URL of Maven Central:

Note that we are working on making Gradle 4.8.1 enable TLSv1.2 by default for Java 7, but as you’ve stated that upgrading is not an option, it will not help.

(Costin caraivan) #3

Upgrading is unlikely, but not impossible. Is this bug being tracked somewhere or should I file it?

Also, would it be possible to expose these settings for extra flexibility for end users?

(Louis Jacomet) #4

Created the issue

(Costin caraivan) #5

Cool! Thanks a lot :+1: