mitmproxy: Certificate Verification Error: unable to get local issuer certificate
Steps to reproduce the problem:
- on CentOS 7, install all dependencies
- install mitmproxy from source code https://github.com/mitmproxy/mitmproxy.git, commit: 8be0d78eaa104996474041bf709ea8aeb7f3637d
- setup proxy server on mobile, install mitmproxy certificate from mitm.it
- open https://baidu.com in browser
What is the expected behavior?
browser works
What went wrong?
browser shows an error message:
502 Bad Gateway. Certificate Verification Error for www.baidu.com: unable to get local issuer certificate (errno: 20, depth: 2)
Here is the log for https://www.baidu.com
111.206.14.134:57025: GET https://www.baidu.com/
<< Certificate Verification Error for www.baidu.com: unable to get local issuer certificate (errno: 20, depth: 2)
https://baidu.com or https://google.com doesn’t work, but some https sites like github.com works. Here is the log for https://github.com
111.206.15.132:52912: CONNECT github.com:443
<< Cannot establish TLS with client (sni: github.com): TlsException("(-1, 'Unexpected EOF')",)
Any other comments? What have you tried so far?
- I tried to update the certificates on centos by
yum install ca-certificates, doesn’t work. - I tried to verify the certificate by openssl on this centos server, it looks good
$ openssl s_client -quiet -connect www.baidu.com:443
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)10, CN = VeriSign Class 3 Secure Server CA - G3
verify return:1
depth=0 C = CN, ST = Beijing, L = Beijing, O = "BeiJing Baidu Netcom Science Technology Co., Ltd", OU = service operation department, CN = baidu.com
verify return:1
- I tried to deploy same version on my Macbook laptop, it works.
Mitmproxy Version: 0.18, commit: 8be0d78eaa104996474041bf709ea8aeb7f3637d Operating System: CentOS 7
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 2
- Comments: 23 (4 by maintainers)
If you don’t care about security, you may run
mitmproxy --insecure(ormitmweb --insecure) to skip verification.The
--insecureoption was deprecated. Use--ssl-insecureinstead.@mhils Ah, thanks for the pointer. Using this, I was able to resolve the error permanently by adding my organization’s internal CA to the
certifipackage included within mitmproxy.For my homebrew-installed copy of mitmproxy, I found the CA list at:
YMMV based on your version and method of installation.
⚠️ Of course, this is only a good idea if you’re sure that the CA can be trusted. If you’re getting CA errors from well-known sites, it may be a sign something fishy is going on (i.e. you may already be being man-in-the-middled by someone else)…
@sryze The reason you don’t see an error in Chrome is that Chrome uses the system’s list of trusted CAs (via the macOS Keychain), while mitmproxy is using openssl, which uses it own separate list of trusted CAs.
One solution would be to update the list of trusted CAs used by mitmproxy, but so far I’m not sure where that is stored (it doesn’t seem to be using the same file as the
opensslcommand line utility, at least not on my Mac)@pimlottc-gov: We use the Python
certifipackage (https://pypi.python.org/pypi/certifi) as the default source for trusted CAs. Unfortunately there’s no good cross-platform solution for using the system CA store. You can use ssl_verify_upstream_trusted_ca (slightly different name on 2.0 I think) to specify a custom file or folder.@kennytm 's comment should be add to the faq.
The error you are seeing happens when we cannot validate the server’s certificate. This may happen because the remote’s server cert is self-signed, but looking at the other reports here, CentOS/RHEL does something weird. Certificate verification errors on the client end would trigger a different message.