You might consider the comment in JENKINS-23050 which recommended a work around from Erik Zaadi's blog

You might also consider the Skip Certificate Check plugin.

I thought the Jenkins Git plugin runs Git from the command line, but the error is a Java error. Why is the URL being hit via Java?

Command line git will prompt for a password if required. Jenkins cannot answer that password prompt, so it makes a best effort (and largely successful effort) to detect if the git command line would prompt for a password before it calls command line git. The failing case is deep inside the Java runtime while the git client plugin was detecting if the call to command line git would have blocked prompting for a password.

Gotcha, so Jenkins hits the URL in advance of calling Git. I fixed the issue by adding the certificate to the cacerts keystore in the JVM that Jenkins is using.

I have the 'skip certificate check' plugin installed, but was still getting the error until I added the certificate. Shouldn't that plugin work in this instance?

@Mark Waite:

Thanks a lot for explaining why there is a connection from Java to the repository even if not JGit but the native git client is configured in Jenkins. This is pretty counter intuitive unless it gets explained.

But couldn't we achieve the same (i.e. find out if a password prompt would block the call) by making a call to curl?

My reasoning is that

a) AFAIK git uses curl, so if curl will work, git will at least not fail because of required but not supplied credentials
b) If the system administrator has made sure that native git will be able to connect to the repository (for example by providing HTTP/S proxy credentials in an environment variable) it will work for curl as well

If git uses curl, then switching to use curl to guess if command line git would block may avoid these self-signed certificate cases.

I'd love to see a pull request with that change proposed, including a set of automated tests to verify it is working correctly.

Currently, I'm working to create automated tests of some relatively simple authenticated access paths (https, ssh, github, bitbucket, local server, etc.). My tests won't check for a self-signed certificate initially, since I don't have a self-signed certificate installed on any of the git servers I use for testing.

The access is working for me if I select to have Jenkins use JGit in the "Configure System" section, use the ssh protocol when specifying the git repo (git@gitHost/repo) and also using ssh keys so that ssh works without asking for password.

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?

The git-client-plugin 1.14.0 release is now available and has removed the call to JGit checkCredentials when using command line git.