我正在将Linux子系统用于Windows和Ubuntu 16.04。以前没有这样的问题。
当前，从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证书，但这没有帮助。我尝试完全禁用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
答案 0 :(得分：1)
我的猜测是Windows中安装了SSL拦截防病毒产品（Avira，Kaspersky，ESET等都具有此类功能，并且默认情况下通常会这样做）。
这对于Windows中的浏览器来说不是问题，因为这些AV还将其根CA安装到系统和浏览器的信任存储中，因此对于Windows上的应用程序透明地工作。 Windows的OS信任库对Linux子系统中的信任库没有影响，尽管如此，该信任库仍会拦截其SSL连接，但不信任AV颁发的证书，因为它不信任由AV使用的CA。 AV。
如果禁用AV或在AV中完成SSL拦截，则该问题可能会消失。
答案 1 :(得分：0)
似乎您已在Windows计算机中安装了Netskope客户端，Netskope客户端本身并不检查ssl流量，但它通过充当代理并提供其自己的证书来破坏直接进入Destination的SSL流量，并将流量发送到Netskope代理用于ssl检查。
通常，当您安装Netskope客户端时，它会同时在Mozilla证书存储区中的System证书存储区中安装CA证书，但是如果您在VM内运行Linux机器，则会收到证书错误，因为添加了CA证书到Windows证书存储区，而不是在Linux中。
要解决此问题：
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