SSL在所有主机上都失败了。（SSL证书问题：证书链中存在自签名证书）

Question

我正在使用带有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.

我不知道是什么原因导致了这个错误。在Windows中一切正常。我使用apt-get卸载并重新安装了openssl和ca-certificates，但没有起到帮助作用。我尝试完全禁用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 = [e-mail]
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 = [e-mail]
verify return:1
depth=1 C = GB, ST = GB, L = London, O = TBWA UK LTD, OU = 47fdec0de5a28c3f38b67c1767c1977e, CN = ca.oss.de.goskope.com, emailAddress = [e-mail]
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 = [e-mail]
 1 s:C = GB, ST = GB, L = London, O = TBWA UK LTD, OU = 47fdec0de5a28c3f38b67c1767c1977e, CN = ca.oss.de.goskope.com, emailAddress = [e-mail]
   i:C = DE, ST = Frankfurt, L = Frankfurt, O = netSkope Inc, OU = Cert Management, CN = caadmin.netskope.com, emailAddress = [e-mail]
 2 s:C = DE, ST = Frankfurt, L = Frankfurt, O = netSkope Inc, OU = Cert Management, CN = caadmin.netskope.com, emailAddress = [e-mail]
   i:C = DE, ST = Frankfurt, L = Frankfurt, O = netSkope Inc, OU = Cert Management, CN = caadmin.netskope.com, emailAddress = [e-mail]
---
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 = [e-mail]

---
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

- Dario Macieira

---

你应该获取证书并显示其内容。你可以使用 openssl s_client 来实现。然后你就会发现它来自哪里。 - Patrick Mevzek

即使不解码和解释证书正文（在-----BEGIN和-----END行之间的base64 blob），s_client也会显示链中每个证书的“(num) s: (subject)”和“i: (issuer)”名称；这通常足以识别来源。但是对于OpenSSL 1.1.1以下版本，请指定-connect host:port -servername host来发送SNI，就像浏览器一样，因为这可能会影响真实服务器或拦截器的证书处理。 - dave_thompson_085

果然，netskope.com出售安全产品，并在其功能列表中列出了“SSL/TLS检查”——换句话说，拦截。他们的CA证书是您需要信任的证书。 - dave_thompson_085

Answer 1

看起来你在Windows机器上安装了Netskope客户端，Netskope客户端本身不会检查SSL流量，但它通过充当代理并呈现自己的证书来中断直接传输到目标的SSL流量，并将流量发送到Netskope代理以进行SSL检查。

通常，在安装Netskope客户端时，它会在系统证书存储和Mozilla证书存储中安装其CA证书，但如果你在VM内运行Linux机器，则会出现证书错误，因为CA证书被添加到Windows证书存储而不是Linux中。

解决方法：

1. 你可以从Windows机器的以下路径获取Netskope CA证书：

C:\ProgramData\netskope\stagent\data

文件：nscacert.pem 和 nstenantcert.pem

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

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

- James Dean

Answer 2

我猜测在Windows中安装了SSL拦截防病毒产品（如Avira，Kaspersky，ESET等），这并不会对Windows中的浏览器造成问题，因为这些AV还会将其根CA安装到系统和浏览器的信任存储中，从而透明地为Windows上的应用程序工作。然而，在Linux子系统中，操作系统信任存储对信任存储没有影响，因此仍会拦截其SSL连接，但不信任由AV发出的证书，因为它对AV使用的CA没有信任。
如果禁用AV或AV中的SSL拦截，则问题可能会消失。

- Steffen Ullrich

---

我按照这篇指南，从 Windows 导出了我的个人证书并将其添加到 Linux，但仍然出现相同的错误。我没有看到与已安装的 AV（Sophos）特定的证书。我想卸载 AV，但我无法控制它。 - Dario Macieira

"我从Windows导出了我的个人证书" - 这不是关于个人证书的问题，而是关于由AV安装的CA证书。 - Steffen Ullrich

我明白了，谢谢。我没有看到我的 AV 安装的证书，我猜它会在 AV 的名称下面？ - Dario Macieira