SSL Certificate Issues when using maven Plugin from Travis

Issue #276 resolved
Adrien SALES created an issue

Since today maven builds are failing, see Job example below :

https://travis-ci.org/DSI-Ville-Noumea/commun/builds/154932968

Stacktrace nelow :

[INFO] --- versioneye-maven-plugin:3.10.2:update (default-cli) @ commun ---
[INFO] File /home/travis/.m2/versioneye.properties does not exist
[INFO] File /home/travis/.m2/versioneye.properties does not exist
[INFO] File /home/travis/.m2/versioneye.properties does not exist
[INFO] File /home/travis/.m2/versioneye.properties does not exist
[INFO] .
[INFO] Starting to update dependencies to server. This can take a couple seconds ... 
[INFO] .
javax.net.ssl.SSLException: Certificate for <www.versioneye.com> doesn't match any of the subject alternative names: [sengaa.versioneye.com]
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:165)
    at org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:61)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:141)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:114)
    at org.apache.http.conn.ssl.SSLSocketFactory.verifyHostname(SSLSocketFactory.java:580)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:554)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:412)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:179)
    at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:328)
    at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:612)

Its seems like it's the same issue than Issue #275

Comments (13)

  1. Robert Reiz

    Hi @adriensales. Sorry for that. Currently testing LetsEncrypt certificates to save some Money. Obviously it's not yet configured the right way. Will work today on this.

  2. Robert Reiz

    @adriensales We created some new SSL certificates for some sub domains via LetsEncrypt, but didn't updated the main cert for the main domain www.versioneye.com. I guess that caused the error. Now ALL domains and sub domains of VersionEye are running on LetsEncrypt certs. Can you please try again and let me know if it's fixed?

  3. Andy Glick

    Robert,

    I used my fork of the versioneye-maven-plugin to attempt to execute versioneye:update. It failed in the same manner as all of the others

    I think that you didn't actually understand me. For better or worse LetsEncrypt certificates are never going to meet your needs, well maybe they might someday, but certainly not anytime soon.

    The problem isn't with your cert exactly, but because LetsEncrypt isn't a known Certificate Authority (CA) the cert chain from your cert to the head of the cert chain (which ends at the LetsEncrypt cert) doesn't end in a root cert that Java programs or browsers can trust. Only Oracle Java JVM's 1.8_101 or better will accept your cert. All other users of versioneye will have to add a cert bundle to their cacerts file.

    I'm afraid that you will need to get a cert from a valid CA, and you probably ought to get a wildcard cert, that way if you have to add servers they can all use the wildcard cert. The wjildcard cert allows you to match on any hostname in the same domain as the others.

    I don't know who suggested to you that using a LetsEncrypt signed cert would solve any problems for you. With a cert chain rooted at the LetsEncrypt cert your cert looks to be self signed to 98% and probably more of all of the programs that could connect to your site.

  4. Robert Reiz

    Hi guys. Today I rolled back to the old SSL cert. The problems are solved now. To bad that we can't use LetsEncrypt :-(

  5. Adrien SALES reporter

    Hi, @reiz , yes, ... but... to good to get the service back up and running ! Thanks for the quick fix and responsive answer on bitbucket ! It makes us feel how versioneye is useful in our daily job ! Have a nice WE ;-p

  6. Andrej Kazakov

    Getting this issue yesterday and today. Are you sure it's fixed?

    The error is slightly different.

    [INFO] [INFO] .
    [INFO] [INFO] Starting to update dependencies to server. This can take a couple seconds ... 
    [INFO] [INFO] .
    [INFO] 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
    [INFO]  at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
    [INFO]  at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
    [INFO]  at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
    

    Thanks

  7. Robert Reiz

    Hi @andrejserafim @adriensales @andyglick @LucBourdil. Our payed SSL certificat expired and I'm not willing to spend Money for a new one, that's why we are using now a free certificate from https://letsencrypt.org/. It's a valid certificate, the problem you are facing only occurs with out-dated JVM versions. Java 8u101 includes the IdenTrust CA. Please update your JVM installation on your side to fix this issue. The subscriptions from VersionEye.com just barely cover the cost for the infrastructure, that's why I'm not willing to spend more Money on it. I hope you understand my situation.

  8. Andrej Kazakov

    @reiz although I appreciate your sentiment, I've been trying to make travis use jdk8u101 with little success. Travis is running with some slightly older linux distros and the apt repos for those stop at u65. :(

  9. Robert Reiz

    @andrejserafim I just asked them on Twitter why they don't update. Alternatively you could run your tests inside of an Docker container. You could use a Docker image which has JVM8 update 101 installed. That's how I run my tests as well.

  10. Adrien SALES reporter

    Hi Robert,

    i completely understand your decision... and i strictly don't have any problem with it... i'd rather be thankful for the service and the job you are doing. Thank you very much. Kind Regards, Adrien

  11. Log in to comment