Refer to "Why Not JGit" at https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-WhyNotJGit for more details

changed from "blocker" to "minor", as this only affects (experimental) jgit implementation, that is known to have some limitations

but...
I have this issue in this plugin too:
https://github.com/jenkinsci/literate-plugin

http.sslverify is a git-cli option, so to support this use case, have to find the equivalent for JGit and provide this as a (global ?) configuration option

Actually, as far as I can tell, this does not only affect the JGit implementation but also the native git implementation. I had a job configured using the native git on a Linux box and was a bit suprised to still see a certification path error message originating from the Java VM like this:

Building in workspace /var/lib/jenkins/workspace/Native git tests
Cloning the remote Git repository
Cloning repository https://github.com/jenkinsci/active-directory-plugin.git
Fetching upstream changes from https://github.com/jenkinsci/active-directory-plugin.git
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1933)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1123)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:254)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:410)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:847)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:880)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
at hudson.model.Run.execute(Run.java:1676)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
ERROR: null
Finished: FAILURE

(Just in case you wonder why there would be any issue with the verfification of the certificate of https://github.com/..., I am living behind a corporate proxy which thinks it's a good idea to proxy TLS for me as well and re-package the connection into a new https:// connection with a certificate which belongs to the proxy. You'd run into the very same issue when accessing your own git repo with https:// with any kind of self-signed, expired or non-matching domain certificate.)

So quickly checking what org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials actually, does, it says

/**

• Check credentials are valid to access the remote repository (avoids git to interactively request username/password.)
  */

In other words: It makes a preliminary attempt to access some URL inside your repo just in order to see if any credentials are required and if so, if you are in posession of any valid set of credentials. Only if that test passes, it will call the actual git client (whichever one) to do the real work. In case that test fails with an exception (as opposed to a controlled "no, you're not authorized"), game is over here even before it would fire up any git client at all.

And as this checkCredentials test is done inside Java, it won't buy you anything if you have set your native git client to ignore TLS cert issues; you just won't get that far.

In order to possibly fix this, I understand one could either omit the whole credentials test as a config option (which would fix the issue for the native client) or introduce an option to tell Java not to try and verify certificates, which I understand depends on the version of the HttpComponents API used.

In case the plugin is on the latest version (4.3), here is what would have to be used:

http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/conn/ssl/TrustSelfSignedStrategy.html

Have you attempted the SSL work around suggested at Erik Zaadi's blog?

not perfect, but for now I was able to solve the problem with this plugin: https://wiki.jenkins-ci.org/display/JENKINS/Skip+Certificate+Check+plugin

@Dominik Bartholdi:

Thanks for the hint. That plugin does indeed give me a chance to get around the problem without any fancy JVM keystore work; though one has to be aware that of course it does disable all SSL cert checking, which is a different goal than to make sure you trust your self-signed certificates, which is what would happen if you go for Mark Waite's suggestion (essentially to use JavaSSL.zip, http://demos.erikzaadi.com/jenkins/JavaSSL.zip).

BUT there are still two things to watch out for:

1. You need to use JGit. If you use the platform native git binary, you will fail (tested with git-client 1.9.1 and git 2.2.2). Funny enough, you will fail somewhere in the JVM, i.e. something in Java tries to do SSL certificate validation (obviously bypassing the Skip Certificate Check Plugin) while you have opted to use the native platform git.

2. Even if you use JGit, the above mentioned issue will lead to an error message in the job configuration dialog like this:

<code>
Failed to connect to repository : sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
</code>

But one can safely ignore it an just go on. The job will clone properly when run as long as you make sure you use JGit in Jenkins. On native git, the error message will be the same, but your clone will break somewhere half-way. (Check the workspace of your job after it broke.)

The call to checkCredentials() has been removed in git-client-plugin from 1.13.1 and beyond. Would you be willing to test a pre-release of git-client-plugin 1.13.1 for this case?

with jgit you can fix it by creating a .gitconfig file in jenkins home with this lines,

[http]
sslVerify = false