当我尝试从qClxswpoi从LiClipse到受SSL保护的git repo进行交互时，我得到了一个对话框，
提供https://git.ffmpeg.org/ffmpeg.git的信息
无法建立与https://git.ffmpeg.org/ffmpeg.git的安全连接，因为无法验证服务器的证书。
SSL报告：PKIX路径构建失败：sun.security.provider.certpath.SunCertPathBuilderException：无法找到请求目标的有效证书路径
是否要跳过此服务器的SSL验证？
跳过此单个git操作的SSL验证[]
跳过存储库/my/workspace/ffmpeg/.git []的git操作的SSL验证
始终从[]开始跳过此服务器的SSL验证
https://git.ffmpeg.org/ffmpeg.git
所以，我得到 [Cancel] [OK]
正在使用LiClipse来处理git pull请求，并且EGit正在通过安装的Java机器来满足请求。我不清楚EGit是使用作为Eclipse的一部分安装的Java机器，还是安装在主机操作系统上的Java机器。我理解是否有一个目录或其他位置，我在其中放置从主机（Eclipse plugin EGit）检索的SSL证书文件。
证书所在的位置在哪里？如何根据我的LiClipse或Eclipse安装的内容以及主机操作系统上的Java实用程序来确定它？
如何从git服务器检索适当的证书？可能以某种方式使用我的浏览器，或者可能是我传递URL或域名的命令行实用程序，但是什么？证书可能是自签名的，这对事情有何影响？
如何将从服务器检索的证书转换为LiClipse或Eclipse可以使用的表单？我运行了一些Java证书实用程序吗？
如何将转换后的证书安装到正确的位置？
我不熟悉Java的SSL和证书处理的术语和架构，因此请解释首字母缩略词和/或指向相应的概述文档。
我在Mac OS X El Capitan 10.11.6上使用基于Eclipse Platform 4.7.1.v20170906-1700的LiClipse 4.3.1.201711062215。
这里有一些相关的页面可以提供部分答案，但是它假定我没有Java架构的知识，或者适用于其他非Eclipse，Egit和LiClipse的基于Java的系统。
正如我们从这个问题中的问号数量中可以看出的那样，这种情况需要将几个知识连接在一起以形成答案。没有一个单独的部分是困难的，虽然一些（LiClipse）是模糊的，并且一些（Java的keytool）在不容易找到的文档中得到解答。
首先解释一下。 Eclipse主要是Java语言代码，它运行在Java: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target上。 “SSL”指的是JRE (Java Runtime Environment)。它后来改名为“TLS”，但我会在这里使用“SSL”。事实证明，SSL通信由JRE处理：“PKIX”指的是提供SSL使用的证书系统的工作组，“communications protocol”表示sun.security.provider正在处理通信。
SSL安全性的一部分是验证，当您要求连接到某个互联网站点（如“git.ffmpeg.org”）时，您实际上是在访问该站点，而不是冒名顶替者。 “Java SE Security architecture”是一小块数据，用于标识目的地名称，并通过发布该证书的服务的数字签名证明该数据的正确性。如果您信任颁发者，并且证书上的签名有效，则可以信任生成的证书所说的内容。发行服务本身有一个证书，由其自己的发放服务依次签署。证书以“certificate”链接到他们的发行人。一些证书和一些发行人锚定了链。这被称为“根证书”。
JRE包含JRE Trust Store中的多个根证书的副本。它存储在JRE的Java Home目录中的文件中，位于chain of trust）。 JRE还包括一个工具./lib/security/cacerts，它可以从Trust Store添加和删除证书。但是JRE并不包括重要的每个根证书。
错误对话告诉我们的是，LiClipse和EGit要求JRE的安全代码将信任链中的证书从git.ffmpeg.org服务器的证书连接到JRE Trust Store中的某个证书。这失败了，因为Trust Store缺少必要的证书。解决方案是将git.ffmpeg.org的证书添加到本地JRE Trust Store。 JRE的./bin/keytool将让我们添加它。 （如果您相信服务器根证书后面的人只有好的参与者的证书，您可以从服务器证书中的信任链中添加根证书。如果您的赌注很高，您可能应该得到一个在信任那么多之前，比这篇博文更好的安全简报。）
所以，我们需要做的是：
首先，我们获取目标服务器的SSL证书git.ffmpeg.org。或者，我们可以从服务器证书的信任链获取根“证书颁发机构”（CA）证书。如果您获得服务器的证书，则只将该服务器标记为受信任。如果您获得CA根证书，则可以使用具有直接或间接从该CA颁发的证书的任何服务器，这可能是更多的服务器。但是，也许你不相信每个CA所做的一切。做出这种权衡超出了这些指令的范围。
获取目标服务器SSL证书的直接方法是通过keytool命令行工具。
OpenSSL
（详细信息：% openssl s_client -connect git.ffmpeg.org:443 </dev/null 2>/dev/null >cert.crt
是SSL / TLS协议客户端的参考实现，它与服务器正确通信并有助于诊断.s_client从stdin读取HTTP命令，因此“openssl s_client”表示法使stdin成为空文件。“</dev/null”符号会将任何输出丢弃到stderr，因此它不会在常规输出中混淆。-connect选项的参数是主机名，'：'，端口名。端口443是https的标准端口协议。来源：a 2>/dev/null。）
这将目标服务器的证书存储在文件SuperUser answer中。它的大小约为2182字节左右。它看起来像这样：
cert.crt或者，您可以使用Firefox Web浏览器（v 57左右）下载目标服务器的证书。导航到-----BEGIN CERTIFICATE-----
MIIGBDCCBOygAwIBAgISA/dw6A9zk496P+FouEc0W3OyMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
... [ 29 lines omitted ] ...
7U4xF6Csg3X76Xx35kIVO/JJOhoDbGIydD1Cya7dba9ZhNFa+KU1uiyu5AX+i4fd
bCXI4Ukqzwc=
-----END CERTIFICATE-----
。关注https://git.ffmpeg.org。
在Chrome和Safari上，它是Mozilla's instructions to view the site's certificate，但你可以获得appears that it is not possible to download the certificate itself，可读但不可重复使用。
根CA证书更难获得。 text file with the certificate information的-showcerts选项将打印出信任链。 openssl s_client，这只是服务器发送的证书。服务器通常不在其信任链的根目录下发送根CA证书。 （请参阅OpenSSL问题Contrary to the documentation's claim。）但是，此选项会在根CA证书上打印出名称。它是服务器发送的最终证书的颁发者。
s_client -showcerts man text misleading: "all certificates in the chain", #4933
根CA证书标识为：“% openssl s_client -connect git.ffmpeg.org:443 -showcerts </dev/null 2>/dev/null
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=ffmpeg.org
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIGBDCCBOygAwIBAgISAzCih69KsBB6DxJc3koSpgrMMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
... [ 29 lines omitted ] ...
Gi010DGiJpnEM3LIcrsokySWppACKkBCcEW3dlAL/kX+8CQrtT+ns8OtAC2RYuMF
jGjs0Nphih0=
-----END CERTIFICATE-----
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
... [ 29 lines omitted ] ...
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
---
”。
有几个地方可以查找根CA证书的集合。每个浏览器都包含它信任的证书集合，并且可以使用该集合查找该文件。但我找到的最简单的来源是MacPorts与openssl一起安装的证书。它们位于OpenSSL数据位置，这是一个将位置编译为OpenSSL的目录。查找名为cert.pem的文件和名为cert /的目录。 （有关更多信息，请参阅Paul Heinlein撰写的/O=Digital Signature Trust Co./CN=DST Root CA X3。）在我的计算机上，它看起来像：
What certificate authorities does OpenSSL recognize?
要列出OpenSSL信任的所有证书文件的路径，可以使用此命令。 （来源：我在StackOverflow上的% openssl version -d OPENSSLDIR: "/opt/local/etc/openssl"
。）
answer to How to list certificates, trusted by OpenSSL?
（如果你想对证书文件做一些不同的事情，你可以使用不同的命令代替上面的“% find -H `openssl version -d | sed -E 's/OPENSSLDIR: "([^"]*)"/\1/'`/(cert.pem|certs) \
-type f -exec ls -l {} \+
lrwxr-xr-x 1 root admin 40 29 Nov 02:05 /opt/local/etc/openssl/cert.pem -> /opt/local/share/curl/curl-ca-bundle.crt
”。）因此，这表明我的OpenSSL安装重用了工具“cUrl”中的ls -l {}。）看着那个文件，我看到它标记了我在服务器证书的/ CN字段中看到的每个证书。此命令使用grep查找并打印该证书。您可以省略-text选项以在开头处取消文本版本：
curl-ca-bundle.crt从“% find -H `openssl version -d | sed -E 's/OPENSSLDIR: "([^"]*)"/\1/'`/(cert.pem|certs) \
-type f -exec grep -B 1 -A 19 'DST Root CA X3' {} \+ | openssl x509 -text
Certificate:
... [ 4 lines omitted ] ...
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Validity
Not Before: Sep 30 21:12:19 2000 GMT
Not After : Sep 30 14:01:15 2021 GMT
Subject: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject Public Key Info:
... [ 45 lines omitted ] ...
-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
... [ 11 lines omitted ] ...
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----
”行到“--BEGIN CERTIFICATE--”行的证书文本是您可以选择在LiClipse中安装的根CA证书。要将该部分放入文件中，请从上面的命令中删除--END CERTIFICATE--选项，并将结果通过管道传输到名为“-text”的文件中。
证书安装在LiClipse使用的DST Root CA X3.crt中。下一个任务是识别此JRE及其Java Runtime Environment (JRE)目录的位置。
幸运的是，问题Java Home在Stack Overflow上。是的，LiClipse for Mac确实包含了自己的JRE。 Java Home目录位于应用程序包中的Does LiClipse (for Mac) include its own copy of the JRE? was answered。 ./jre/Contents/Home子目录具有可执行文件，就像主java可执行文件一样。
./binJava JRE包括一个命令行实用程序keytool，用于管理该JRE的密钥。该实用程序位于JRE内的% cd /Applications/LiClipse\ 4.0.0/LiClipse.app/jre/Contents/Home
% ls -F
COPYRIGHT THIRDPARTYLICENSEREADME.txt man/
LICENSE Welcome.html release
README bin/
THIRDPARTYLICENSEREADME-JAVAFX.txt* lib/
% bin/java -version
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
。您可以通过阅读./bin/keytool了解更多信息。您还可以使用其keytool documentation选项运行keytool，并阅读keytool手册页（使用“-help”获取JRE的手册页，而不是系统的。）而且，虽然许多关于keytool的网页都会假设Windows并说“keytool”。 exe“，在Mac上你当然不使用”.exe“扩展名。
man -M man/这个keytool是我们用来将密钥添加到Trust Store的。
JRE将在不同位置查找密钥。默认值为% cd /Applications/LiClipse\ 4.0.0/LiClipse.app/jre/Contents/Home
% man -M man/ keytool
... [man page omitted] ...
% bin/keytool -help
Key and Certificate Management Tool
... [20 lines omitted] ...
Use "keytool -command_name -help" for usage of command_name
，与当前用户绑定的位置，该用户的所有JRE都可以查询。默认情况下，此位置没有任何内容。回退位置位于JRE的Java主目录下，文件为~/.keystore。
这些位置是关于Java安全架构的更大故事的一部分，我将不会在这里介绍。你可以通过阅读./lib/security/cacerts和Terms section of the keytool documentation开始学习它。您将看到术语“密钥库”，它与“信任库”相关。有时这些术语可以互换使用。出于我们的目的，“Trust Store”是正确的术语。
权宜之计是修改JRE的本地Trust Store。路径在上面。 Java Cryptography Architecture (JCA) Reference Guide告诉我们它的初始密码是“cacerts section of the keytool documentation”。对于LiClipse JRE，这可能仍然是它的密码。
剩下的就是将这些碎片放在一起。使用keytool将新服务器SSL证书或根CA证书添加到LiClipse JRE的Trust Store。
changeit通过阅读手册页可以清楚地看到keytool调用。总结一下：% cd /Applications/LiClipse\ 4.0.0/LiClipse.app/jre/Contents/Home
% bin/keytool -import -alias FFmpeg.org -file cert.crt -keystore lib/security/cacerts -storepass changeit
Owner: CN=ffmpeg.org
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Serial number: 3f770e80f73938f7a3fe168b847345b73b2
Valid from: Tue Oct 31 23:22:03 PDT 2017 until: Mon Jan 29 22:22:03 PST 2018
Certificate fingerprints:
MD5: 61:57:B5:6B:56:08:B9:ED:E8:EC:EC:85:A9:CA:1A:F4
SHA1: 75:1B:86:CD:1E:34:7C:13:2F:49:E2:6D:73:A0:4F:05:09:11:7B:72
SHA256: EB:FA:E4:3F:CB:22:31:9F:97:7B:FA:E4:79:D6:90:7F:E0:20:3E:DA:E8:6F:C3:F0:38:55:F7:C0:1E:0D:6A:33
Signature algorithm name: SHA256withRSA
Version: 3
....
Trust this certificate? [no]: yes
Certificate was added to keystore
命令keytool添加证书，-import为商店中的证书提供标题，-alias给出了从中读取证书的文件路径，-file给出了密钥库的路径（没有它，默认将使用-keystore），~/.keystore提供该密钥库的密码。您可以添加选项-storepass以减少工具的注释，并选择-noprompt来停止关于信任证书的问题，但是对于这样的用途，我喜欢进行交叉检查。
如果您愿意，相同的调用将导入根CA证书。
接下来，我们测试更改是否有效。尝试再次在LiClipse下使用EGit从ffmpeg.org执行“git pull”。这次，没有出现错误对话框。这表示JRE的安全代码将信任链中的证书从git.ffmpeg.org服务器的证书连接到JRE Trust Store中的某个证书。 （如果您在JRE Trust Store中安装了服务器的证书，那么这是一个1证书链。）
这是我写的关于这个主题的博客文章-trustcacerts的缩写。