[英]SSL fails with all hosts. (SSL certificate problem: self signed certificate in certificate chain)
I'm using the Linux subsystem for Windows with Ubuntu 16.04.我将 Linux 子系统用于 Windows 和 Ubuntu 16.04。 Haven't had any problems such as this before.
以前没有遇到过这样的问题。
Currently any attempt to use SSL from Ubuntu (curl, python, anything etc.) returns an error along the lines of "self signed certificate in certificate chain".目前,任何从 Ubuntu (卷曲、python 等)使用 SSL 的尝试都会返回错误,类似于“证书链中的自签名证书”。
Running:跑步:
curl -v https://accounts.google.com
curl -v https://accounts.google.com
returns:返回:
* 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.
I have no idea what is causing the error.我不知道是什么导致了错误。 In Windows everything works fine.
在 Windows 一切正常。 I removed and reinstalled openssl and ca-certificates with apt-get but that didn't help.
我使用 apt-get 删除并重新安装了 openssl 和 ca-certificates,但这并没有帮助。 I tried completely disabling the Windows Firewall but that didn't help either.
我尝试完全禁用 Windows 防火墙,但这也无济于事。 Currently my workaround is to disable verification of certificates but that obviously isn't a long-term solution.
目前我的解决方法是禁用证书验证,但这显然不是一个长期的解决方案。
Edit: Using "openssl s_client -connect accounts.google.com:443" returns:编辑:使用“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
It seems like you have Netskope client installed in Windows machine, Netskope client doesn't itself inspect ssl traffic but it breaks the SSL traffic going directly to Destination by acting as a proxy and present its own certificate and sends traffic to Netskope proxy for ssl inspection. It seems like you have Netskope client installed in Windows machine, Netskope client doesn't itself inspect ssl traffic but it breaks the SSL traffic going directly to Destination by acting as a proxy and present its own certificate and sends traffic to Netskope proxy for ssl inspection .
Generally, when you install Netskope client, it installs it's CA cert in System cert store also in Mozilla cert store but if you're running Linux machine inside a VM, you'll get the cert error because the CA certs are added to Windows cert store, not in Linux.通常,当您安装 Netskope 客户端时,它会将其 CA 证书安装在系统证书存储中以及 Mozilla 证书存储中,但如果您在 VM 中运行 Linux 机器,您将收到证书错误,因为 CA 证书已添加到 Windows 证书存储,不在 Linux 中。
To solve this:要解决这个问题:
C:\ProgramData\netskope\stagent\data C:\ProgramData\netskope\stagent\data
Files: nscacert.pem and nstenantcert.pem文件:nscacert.pem 和 nstenantcert.pem
use these PAM files and add it to Linux Ca-certificates lists.使用这些 PAM 文件并将其添加到 Linux Ca 证书列表中。 Probably at /usr/local/share/ca-certificates/ and run update-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 https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu
My guess is that there is an SSL intercepting antivirus product installed in Windows (Avira, Kaspersky, ESET, ... all have such capabilities and often do it by default).我的猜测是在 Windows 中安装了一个 SSL 拦截防病毒产品(Avira、Kaspersky、ESET ......都有这样的功能,并且通常默认情况下这样做)。
This is not a problem for browsers in Windows since these AV also install their root CA into the trust stores of the system and of the browsers and thus work transparently for applications on Windows.这对于 Windows 中的浏览器来说不是问题,因为这些 AV 还将其根 CA 安装到系统和浏览器的信任库中,因此对 Windows 上的应用程序透明地工作。 The OS trust store from Windows has no effect on the trust store(s) in the Linux subsystem though which therefore still gets its SSL connections intercepted but does not trust the certificate issued by the AV since it has no trust in the CA used by the AV.
来自 Windows 的操作系统信任库对 Linux 子系统中的信任库没有影响,尽管它因此仍然获得其 SSL 连接,但不信任 CA 所使用的证书,因为它不信任被拦截的 AV 连接发出的证书。影音。
If you disable the AV or the SSL interception done in the AV the problem will likely vanish.如果禁用 AV 或在 AV 中完成的 SSL 拦截,问题可能会消失。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.