# Gradle can't access Maven repos over TLS servers using SNI

**URL:** <https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986>\
**Category:** Bugs\
**Created:** [October 2, 2015, 12:23am UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986 "2015-10-02T00:23:51Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![chiralsoftware](https://avatars.discourse-cdn.com/v4/letter/c/c77e96/32.png) [@chiralsoftware](https://discuss.gradle.org/u/chiralsoftware)\
**Post date:** [October 2, 2015, 12:23am UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/1 "2015-10-02T00:23:51Z")

</div>

Hi everyone, my first post here.

I’m using Gradle 2.8rc1 with some dependency from a private maven repos. The build.gradle looks like:

```
    maven {
        url "https://foo.example.com/maven"
    }

```

This _should_ work fine. The problem is that [foo.example.com](http://foo.example.com) is secured with TLS1.2 including SNI. This is causing the following result:

```
hostname in certificate didn't match: <foo.example.com> != <example.com> OR <example.com> OR <www.example.com>

```

Which is caused by:

```
Caused by: javax.net.ssl.SSLException: hostname in certificate didn't match: <foo.example.com> != <example.com> OR <example.com> OR <www.example.com>
	at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)

```

Looking into it some more, I’m 99% sure this is caused by using Apache HttpClient version prior to 4.3.2, and is [due to this bug](https://issues.apache.org/jira/browse/HTTPCLIENT-1119). I confirm that Gradle 2.8rc1 is using httpclient-4.2.2.jar, so it is impacted by that bug and cannot access SNI sites correctly.

Can anyone confirm if this is what is going on, and if so, I believe that this is a bug which should be fixed prior to release of Gradle 2.8, due to the wide use of SNI at this point. I believe the fix is simply upgrading to a more recent HttpClient.

Thanks

---

<div class="post-metadata">

**Author:** ![mark\_vieira](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/mark_vieira/32/5396_2.png) [@mark\_vieira](https://discuss.gradle.org/u/mark_vieira)\
**Post date:** [October 2, 2015, 9:20pm UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/2 "2015-10-02T21:20:47Z")

</div>

This is a known issue, tracked as GRADLE-3250. We’re tentative to simply upgrade HttpClient versions as it may introduce regressions for some functionality like NTLM and Kerberos support that we are currently lacking adequate test coverage for.

---

<div class="post-metadata">

**Author:** ![chiralsoftware](https://avatars.discourse-cdn.com/v4/letter/c/c77e96/32.png) [@chiralsoftware](https://discuss.gradle.org/u/chiralsoftware)\
**Post date:** [October 2, 2015, 9:38pm UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/3 "2015-10-02T21:38:48Z")

</div>

Thank you Mark. That’s exactly it, and there’s a full discussion of it. I agree with comment at the end of the bug. TLS is normal these days, and is essential for important things like build artifacts, and everyone is now using SNI. I hope Gradle will consider this as a high-priority fix for 2.8. I had to reconfigure my web server to carve out a build artifacts directory that it will serve as non-TLS. It’s no big deal to configure but turning off encryption is always a step backwards.

---

<div class="post-metadata">

**Author:** ![mark\_vieira](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/mark_vieira/32/5396_2.png) [@mark\_vieira](https://discuss.gradle.org/u/mark_vieira)\
**Post date:** [October 2, 2015, 9:43pm UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/4 "2015-10-02T21:43:13Z")

</div>

> [@chiralsoftware](#):
>
> I had to reconfigure my web server to carve out a build artifacts directory that it will serve as non-TLS.

I just want to clarify that the version of HTTP client we are on does in fact support TLS, just not the SNI extensions. If you have the ability to reconfigure the webserver you are hosting your artifacts from you might consider using a single combination of (IP address, hostname, SSL certificate) to get around this problem rather than resorting to disabling TLS entirely.

---

<div class="post-metadata">

**Author:** ![noseglid](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/noseglid/32/5054_2.png) [@noseglid](https://discuss.gradle.org/u/noseglid)\
**Post date:** [April 14, 2016, 1:28pm UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/5 "2016-04-14T13:28:31Z")

</div>

Hello,

We’re experiencing the same issues, but when publishing artifacts to the maven repository.  
Our server relies on SNI to correctly determine which certificate to present.

It looks like [Gradle is using 2.4 of the wagon libraries](https://github.com/gradle/gradle/blob/master/gradle/dependencies.gradle#L126-L129), which in turn [uses 4.2.3 of org.apache.httpcomponents](https://github.com/apache/maven-wagon/blob/wagon-2.4/wagon-providers/pom.xml#L52-L54). Support for SNI was [added in version 4.3.2](https://issues.apache.org/jira/browse/HTTPCLIENT-1119).

This is via [the Maven plugin](https://github.com/gradle/gradle/tree/master/subprojects/maven) which we use via [gradle-nexus-plugin](https://github.com/bmuschko/gradle-nexus-plugin) (but the result should be the same by using the Maven plugin’s `uploadArchives` directly).

Any chance we can look at upgrading this? SNI has been available since 2004 and isn’t exactly a new technique.

---

<div class="post-metadata">

**Author:** ![noseglid](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/noseglid/32/5054_2.png) [@noseglid](https://discuss.gradle.org/u/noseglid)\
**Post date:** [April 14, 2016, 1:37pm UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/6 "2016-04-14T13:37:03Z")

</div>

(Since I’m only allowed to put 5 links in one post, this a continuation on above…)

For some reason the Maven plugin uses apache http client via `wagon`, so the [fixes in gradle version 2.11 regarding this](https://issues.gradle.org/browse/GRADLE-3250) does not solve this issue. We can however correctly pull artifacts.

As a work-around, we’re putting `-Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true` in our gradle command, which is not good for obvious reasons.

---

<div class="post-metadata">

**Author:** ![mark\_vieira](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/mark_vieira/32/5396_2.png) [@mark\_vieira](https://discuss.gradle.org/u/mark_vieira)\
**Post date:** [April 14, 2016, 9:33pm UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/7 "2016-04-14T21:33:52Z")

</div>

> [@noseglid](#):
>
> For some reason the Maven plugin uses apache http client via wagon, so the fixes in gradle version 2.11 regarding this does not solve this issue. We can however correctly pull artifacts.

This is correct. You can however use the [maven-publish plugin](https://docs.gradle.org/current/userguide/publishing_maven.html) which does take advantage of the upgrade to HttpClient 4.4.1 in 2.11.

---

<div class="post-metadata">

**Author:** ![noseglid](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/noseglid/32/5054_2.png) [@noseglid](https://discuss.gradle.org/u/noseglid)\
**Post date:** [April 15, 2016, 9:12am UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/8 "2016-04-15T09:12:30Z")

</div>

Changing to the `maven-publish`-plugin require quite some changes for us.  
Do you not want to update the wagon dependencies?

---

<div class="post-metadata">

**Author:** ![mark\_vieira](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/mark_vieira/32/5396_2.png) [@mark\_vieira](https://discuss.gradle.org/u/mark_vieira)\
**Post date:** [April 15, 2016, 7:52pm UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/9 "2016-04-15T19:52:24Z")

</div>

> [@noseglid](#):
>
> Do you not want to update the wagon dependencies?

Upgrading these libraries is definitely a possibility. Would you consider contributing a pull request for this?

---

<div class="post-metadata">

**Author:** ![noseglid](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/noseglid/32/5054_2.png) [@noseglid](https://discuss.gradle.org/u/noseglid)\
**Post date:** [April 18, 2016, 2:14pm UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/10 "2016-04-18T14:14:36Z")

</div>

I tried, and it is not trivial (i.e… just updating the version wasn’t enough, it complained about classes not existing when I tried to compile it. Didn’t dig any deeper.). I don’t think I’ll have time anytime soon ☹

---

<div class="post-metadata">

**Author:** ![noseglid](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/noseglid/32/5054_2.png) [@noseglid](https://discuss.gradle.org/u/noseglid)\
**Post date:** [May 2, 2016, 6:33am UTC](https://discuss.gradle.org/t/gradle-cant-access-maven-repos-over-tls-servers-using-sni/11986/11 "2016-05-02T06:33:45Z")

</div>

For the record, we tried to update to the new `maven-publish` plugin, but that doesn’t support signing artifacts yet,which is required by the maven repository we have. Hence we have no option but to disable host verification in the `Maven` plugin.
