"cannot open git-upload-pack" - Cloning project in Eclipse IDE - eclipse

Question

I'm making a clone of my project that is in Github in the Eclipse IDE.
After entering all the access data, the following error occurs:
https://github.com/"COMPANY NAME"/"PROJECTNAME".git: cannot open git-upload-pack
I already added the http.sslVerify = false - did not work
I configured the RSA key - did not work either
I use: Windows 10 / Java 7 / Eclipse Luna Luna Service Release 2 (4.4.2)
More details of the error
org.eclipse.jgit.api.errors.TransportException:
https://github.com/"COMPANYNAME"/"PROJECTNAME".git: cannot open git-upload-pack
at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:196)
at
org.eclipse.egit.core.op.ListRemoteOperation.run(ListRemoteOperation.java:99)
at org.eclipse.egit.ui.internal.clone.SourceBranchPage$8.run(SourceBranchPage.java:324)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
Caused by: org.eclipse.jgit.errors.TransportException: https://github.com/"COMPANYNAME"/"PROJECTNAME".git: cannot open git-upload-pack
at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:521)
at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:309)
at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:175)
... 3 more
Caused by: javax.net.ssl.SSLException: Received fatal alert: protocol_version
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
at org.eclipse.jgit.transport.http.JDKHttpConnection.getResponseCode(JDKHttpConnection.java:98)
at org.eclipse.jgit.util.HttpSupport.response(HttpSupport.java:168)
at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:475)
... 5 more
Session Data:
eclipse.buildId=4.4.2.M20150204-1700
java.version=1.7.0_79
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=pt_BR
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product
org.eclipse.epp.package.jee.product

Answer 1

Try this answer to a related question on Salesforce Stack Exchange. It worked for me.
To elaborate, GitHub recently (as of February 8, 2018) removed support for a number of outdated cryptographic standards. See this announcement for more details on that.
Unfortunately, this list includes TLSv1, which is the default TLS implementation used by Java 7. I encountered the same problem since I was interfacing with GitHub via EGit on a fairly ancient Eclipse build still using Java 7, and sure enough, it was explicitly set to use TLS1.0. I followed the recommended steps to force my Java to use TLS1.1 and 1.2, and the problem was magically solved.

Answer 2

Eclipse 2019-12 has an issue running on IBM JDK that implements
SSLContext.getInstance("TLS")
differently than the other JDKs like Oracle JDK or OpenJDK.
The issue is explained in this Eclipse forum post
To resolve the issue you need to set a runtime parameter:
-Dcom.ibm.jsse2.overrideDefaultTLS=true
in the eclipse.ini file.
also, if still not working, you need to add one of the following parameters:
-Dhttps.protocols=TLSv1.1,TLSv1.2
-Djdk.tls.client.protocols=TLSv1.1,TLSv1.2
Some people observed that in some contexts the order of the items do count, so
-Dhttps.protocols=TLSv1.2,TLSv1.1
is not the same with
-Dhttps.protocols=TLSv1.1,TLSv1.2
The last in the list tend to have priority in front of the others.
Other official articles from IBM explaining the "functionality" are the following:
IBM Article 1
IBM Article 2
IBM Article 3