所有主机的 SSL 均失败。（SSL证书问题：证书链中的自签名证书）

Question

所有主机的 SSL 均失败。（SSL证书问题：证书链中的自签名证书）

Dar*_*ira 3 ssl curl openssl ssl-certificate

我在 Ubuntu 16.04 上使用适用于 Windows 的 Linux 子系统。以前没有遇到过这样的问题。

目前，任何从 Ubuntu（curl、python、任何东西等）使用 SSL 的尝试都会返回“证书链中的自签名证书”这样的错误。

跑步：

curl -v https://accounts.google.com

返回：

*   Trying 172.217.12.77...
* TCP_NODELAY set
* Expire in 149889 ms for 3 (transfer 0x7fffe443e570)
* Expire in 200 ms for 4 (transfer 0x7fffe443e570)
* Connected to accounts.google.com (172.217.12.77) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /home/<username>/anaconda3/ssl/cacert.pem
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Run Code Online (Sandbox Code Playgroud)

我不知道是什么导致了错误。在 Windows 中一切正常。我使用 apt-get 删除并重新安装了 openssl 和 ca 证书，但这没有帮助。我尝试完全禁用 Windows 防火墙，但这也无济于事。目前我的解决方法是禁用证书验证，但这显然不是一个长期解决方案。

编辑：使用“openssl s_client -connect accounts.google.com:443”返回：

CONNECTED(00000004)
depth=2 C = DE, ST = Frankfurt, L = Frankfurt, O = netSkope Inc, OU = Cert Management, CN = caadmin.netskope.com, emailAddress = certadmin@netskope.com
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=2 C = DE, ST = Frankfurt, L = Frankfurt, O = netSkope Inc, OU = Cert Management, CN = caadmin.netskope.com, emailAddress = certadmin@netskope.com
verify return:1
depth=1 C = GB, ST = GB, L = London, O = TBWA UK LTD, OU = 47fdec0de5a28c3f38b67c1767c1977e, CN = ca.oss.de.goskope.com, emailAddress = certadmin@netskope.com
verify return:1
depth=0 CN = *.accounts.google.com
verify return:1
---
Certificate chain
 0 s:CN = *.accounts.google.com
   i:C = GB, ST = GB, L = London, O = TBWA UK LTD, OU = 47fdec0de5a28c3f38b67c1767c1977e, CN = ca.oss.de.goskope.com, emailAddress = certadmin@netskope.com
 1 s:C = GB, ST = GB, L = London, O = TBWA UK LTD, OU = 47fdec0de5a28c3f38b67c1767c1977e, CN = ca.oss.de.goskope.com, emailAddress = certadmin@netskope.com
   i:C = DE, ST = Frankfurt, L = Frankfurt, O = netSkope Inc, OU = Cert Management, CN = caadmin.netskope.com, emailAddress = certadmin@netskope.com
 2 s:C = DE, ST = Frankfurt, L = Frankfurt, O = netSkope Inc, OU = Cert Management, CN = caadmin.netskope.com, emailAddress = certadmin@netskope.com
   i:C = DE, ST = Frankfurt, L = Frankfurt, O = netSkope Inc, OU = Cert Management, CN = caadmin.netskope.com, emailAddress = certadmin@netskope.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID8jCCAtqgAwIBAgIQGCu6BLIHRaW5ajAUR6l3nDANBgkqhkiG9w0BAQsFADCB
...
IuyKTaSo
-----END CERTIFICATE-----
subject=CN = *.accounts.google.com

issuer=C = GB, ST = GB, L = London, O = TBWA UK LTD, OU = 47fdec0de5a28c3f38b67c1767c1977e, CN = ca.oss.de.goskope.com, emailAddress = certadmin@netskope.com

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3910 bytes and written 401 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self signed certificate in certificate chain)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: DC5244B88B2BD84F10696D872393D7F526B3FA174278F1B6B2F26AE57C7FE8B5
    Session-ID-ctx:
    Resumption PSK: F0A7FB5E51C7296C40FF669B5A7E6B47DD1F4B1CD6E3FEBF7F6B5D3BAF70A57FFE74F536298EB57CF2C8803FED10BECE
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 90 e0 87 ea 85 33 01 dc-7d 2a 3d 33 e2 47 34 45   .....3..}*=3.G4E
    ...
    00c0 - 43 e8 a3 e3 79 b1 c5 86-5c 4b ee c0 d6 5c 74 84   C...y...\K...\t.

    Start Time: 1571235994
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 2DFF6D4B774F97F3E6EE7710B1159D8C3357970111CBCCBB1A56CFB7B2490C4F
    Session-ID-ctx:
    Resumption PSK: 3910D4FF6C327569EEF7A4C4B346E21CCEBE4BB4789E3CF065967601D0580638D124AA96B282B3AF908D4F8D59D4950A
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 90 e0 87 ea 85 33 01 dc-7d 2a 3d 33 e2 47 34 45   .....3..}*=3.G4E
    ...
    00c0 - e6 c1 09 c9 3d 40 c6 3e-ca ee 00 cd fe 35 51 c9   ....=@.>.....5Q.

    Start Time: 1571235995
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

Run Code Online (Sandbox Code Playgroud)

Answer 1

Jam*_*ean 8

似乎您在 Windows 机器上安装了 Netskope 客户端，Netskope 客户端本身并不检查 ssl 流量，但它通过充当代理来中断直接到目的地的 SSL 流量并提供自己的证书，并将流量发送到 Netskope 代理进行 ssl 检查.

通常，当您安装 Netskope 客户端时，它会在系统证书存储中也安装在 Mozilla 证书存储中的 CA 证书，但是如果您在 VM 中运行 Linux 机器，则会收到证书错误，因为 CA 证书已添加到 Windows 证书中store ，而不是在 Linux 中。

要解决这个问题：

您可以通过以下路径从 Windows 机器获取 Netskope CA 证书：

C:\ProgramData\netskope\stagent\data

文件：nscacert.pem 和 nstenantcert.pem

使用这些 PAM 文件并将其添加到 Linux Ca 证书列表中。可能在 /usr/local/share/ca-certificates/ 并运行 update-ca-certificates

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu

Answer 2

Ste*_*ich 1

我的猜测是，Windows 中安装了 SSL 拦截防病毒产品（Avira、卡巴斯基、ESET...都具有此类功能，并且通常默认情况下这样做）。

对于 Windows 中的浏览器来说这不是问题，因为这些 AV 还将其根 CA 安装到系统和浏览器的信任存储中，从而对 Windows 上的应用程序透明地工作。来自 Windows 的操作系统信任存储对 Linux 子系统中的信任存储没有影响，因此 Linux 子系统的 SSL 连接仍会被拦截，但不信任 AV 颁发的证书，因为它不信任 AV 使用的 CA AV。

如果禁用 AV 或在 AV 中执行 SSL 拦截，问题可能会消失。

归档时间：	6 年，1 月前
查看次数：	5821 次
最近记录：	6 年前