我在 AWS 私有(private)云(公司网络)中的 CentOS 7 服务器无法连接到某些站点。经过一些工作后，我设法将问题缩小为以下问题。
(1) 无法访问以下内部站点(公共(public) CA 的 SSL):
curl -v https://git.example.com
返回:
About to connect() to git.example.com port 443 (#0)
Trying 10.62.124.6...
Connected to git.example.com (10.62.124.6) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
(2) 但遵循内部站点工作(公共(public) CA 的 SSL):
curl -v https://alm.example.com
返回:
About to connect() to alm.example.com port 443 (#0)
Trying 10.64.167.137...
Connected to alm.example.com (10.64.167.137) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
...
...
...
Accept: */*
知道为什么数字 (1) 不起作用吗？这些都是受同一公共(public) CA 信任的内部站点。
感谢您的帮助。
最佳答案
原来是我们公司的下面这个案例。 git.example.com 托管在私有(private) Azure 中，并且 alm.example.com 托管在私有(private) AWS 中。我的工作服务器也恰好在 AWS 中，这就是为什么 Azure 的服务器在网络中遇到了一些问题。根据网络团队的建议，我将 Linux 内核中的 MTU 大小设置为 1350，这已得到解决。
此外，我们公司还开始拦截 SSL 流量，他们在代理中安装了中间证书，并希望所有内部服务器都信任该证书。我上面提到的问题是由于这两个问题的混合，证书问题可以通过信任它或忽略 SSL 验证来解决。
希望这对某人有帮助。
关于linux - Curl 的证书问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52705627/