New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificate Verification Error: unable to get local issuer certificate #1608

Closed
passos opened this Issue Oct 13, 2016 · 20 comments

Comments

Projects
None yet
@passos

passos commented Oct 13, 2016

Steps to reproduce the problem:
  1. on CentOS 7, install all dependencies
  2. install mitmproxy from source code https://github.com/mitmproxy/mitmproxy.git, commit: 8be0d78
  3. setup proxy server on mobile, install mitmproxy certificate from mitm.it
  4. 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?
  1. I tried to update the certificates on centos by yum install ca-certificates, doesn't work.
  2. 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
  1. I tried to deploy same version on my Macbook laptop, it works.

Mitmproxy Version: 0.18, commit: 8be0d78
Operating System: CentOS 7

@mhils

This comment has been minimized.

Member

mhils commented Oct 14, 2016

Thanks for the report!
I cannot reproduce this on Ubuntu or Windows. If I understand you correctly, you also tried OSX and that worked, so it's presumably a CentOS issue? mitmproxy uses the certifi CA bundle by default, not the OS ca-certificates bundle.

Two questions for you:

  1. Which certifi version are you running?
  2. Which version of OpenSSL are you using (as reported by mitmproxy --sysinfo)?
@mhils

This comment has been minimized.

Member

mhils commented Oct 22, 2016

Closing this for inactivity, please let comment here if the issue still persists!

@mhils mhils closed this Oct 22, 2016

@danielguerra69

This comment has been minimized.

danielguerra69 commented Oct 24, 2016

I had the same using libressl. With openssl it's working fine

@mounty1

This comment has been minimized.

mounty1 commented Nov 3, 2016

Also encountering this on OEL, which is based on CentOS/Red-Hat:

$ mitmproxy --sysinfo
Mitmproxy version: 0.18.2
Python version: 2.7.5
Platform: Linux-4.1.12-32.el7uek.x86_64-x86_64-with-oracle-7.2
SSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Linux distro: Oracle Linux Server 7.2
@chinalu

This comment has been minimized.

chinalu commented Nov 18, 2016

I have the same problem:

mitmproxy --sysinfo

Mitmproxy version: 0.18.2
Python version: 2.7.11
Platform: Linux-2.6.32-431.el6.x86_64-x86_64-with-centos-6.5-Final
SSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Linux distro: CentOS 6.5 Final

@zts-rbecker

This comment has been minimized.

zts-rbecker commented Nov 18, 2016

Seeing the same issue trying to access www.google.com through mitmproxy:
mitmproxy --sysinfo

Mitmproxy version: 0.18.2
Python version: 2.7.11
Platform: Linux-2.6.32-431.29.2.el6.x86_64-x86_64-with-centos-6.5-Final
SSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Linux distro: CentOS 6.5 Final

@SriVR

This comment has been minimized.

SriVR commented Dec 1, 2016

Me too facing same issues
mitmproxy --sysinfo
Mitmproxy version: 0.18.2
Python version: 3.5.2
Platform: Linux-2.6.32-642.4.2.el6.x86_64-x86_64-with-redhat-6.8-Santiago
SSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Linux distro: Red Hat Enterprise Linux Workstation 6.8 Santiago

@Son9o

This comment has been minimized.

Son9o commented Dec 18, 2016

https://www.google.com/loc/m/api
← Certificate Verification Error for www.google.com: unable to get local issuer certificate (errno: 20, depth: 2)
Mitmproxy version: 0.19
Python version: 3.5.1
Platform: Linux-3.10.0-514.2.2.el7.x86_64-x86_64-with-centos-7.3.1611-Core
SSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Linux distro: CentOS Linux 7.3.1611 Core

using as transparent proxy for android app debugging, could it be perhaps that android app is checking against it's own bundle?

@mhils

This comment has been minimized.

Member

mhils commented Dec 18, 2016

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.

@kennytm

This comment has been minimized.

kennytm commented Dec 24, 2016

If you don't care about security, you may run mitmproxy --insecure (or mitmweb --insecure) to skip verification.

@avyang

This comment has been minimized.

avyang commented Jan 19, 2017

I have the same issue on centos 7:
Mitmproxy version: 1.0.2
Python version: 3.6.0
Platform: Linux-3.10.0-327.10.1.el7.x86_64-x86_64-with-centos-7.2.1511-Core
SSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Linux distro: CentOS Linux 7.2.1511 Core

but no problem on ubuntu 16.04:
Mitmproxy version: 1.0.1
Python version: 3.5.2
Platform: Linux-4.4.0-59-generic-x86_64-with-Ubuntu-16.04-xenial
SSL version: OpenSSL 1.0.2g 1 Mar 2016
Linux distro: Ubuntu 16.04 xenial

It is ok while I connect www.baidu.com:443 using openssl on centos 7:
openssl s_client -connect www.baidu.com:443
CONNECTED(00000003)
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 = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
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

Certificate chain
0 s:/C=CN/ST=beijing/L=beijing/O=BeiJing Baidu Netcom Science Technology Co., Ltd/OU=service operation department./CN=baidu.com
i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
i:/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
2 s:/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
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Server certificate
-----BEGIN CERTIFICATE-----
MIIHOjCCBiKgAwIBAgIPAaAMWZKgoUJvdRQzvVy/MA0GCSqGSIb3DQEBCwUAMH4x
CzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0G
A1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEvMC0GA1UEAxMmU3ltYW50ZWMg
Q2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzQwHhcNMTYwODE1MDAwMDAwWhcN
MTcwODE2MjM1OTU5WjCBqDELMAkGA1UEBhMCQ04xEDAOBgNVBAgMB2JlaWppbmcx
EDAOBgNVBAcMB2JlaWppbmcxOTA3BgNVBAoMMEJlaUppbmcgQmFpZHUgTmV0Y29t
IFNjaWVuY2UgVGVjaG5vbG9neSBDby4sIEx0ZDEmMCQGA1UECwwdc2VydmljZSBv
cGVyYXRpb24gZGVwYXJ0bWVudC4xEjAQBgNVBAMMCWJhaWR1LmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsV6Ty0lfOjGN04Pmd8m0OuU0aWrFnm
KqsvkcxEtFfT9lgyhrZe3Tbyq7xjMsNluuJFeRlvxgszGgS/LNxfpkaY6sg67R/t
vaxB8LmuIJn9e7RI3dZUoyZDTBFWTovVsdoOlnF00YRRKN9tbKo1rK4rzux+gqRt
f4Hsk+mjTBhPkY0J/4qocUGeGYxPjHlPIJABBN5UttUv3Be10fhUzP1OHHyj+iYq
K/PsMIo+PoZclb0ox1K4Vvg3czjy8BAF76sw+mqr/w/v16WemjFADyIqoUXuBQyh
p3h4FmgmiXSRJeJ8ik9tzzjdIb0KhrRbdjQJyA4pDujYKk2g+4Ht2R0CAwEAAaOC
A4gwggOEMIIBMwYDVR0RBIIBKjCCASaCCyouYmFpZHUuY29tgg4qLmJhaWZ1YmFv
LmNvbYIOKi5iZHN0YXRpYy5jb22CDCouaGFvMTIzLmNvbYILKi5udW9taS5jb22C
DyouYmNlLmJhaWR1LmNvbYIQKi5leXVuLmJhaWR1LmNvbYIPKi5tYXAuYmFpZHUu
Y29tggliYWlkdS5jb22CDGJhaWZ1YmFvLmNvbYIMd3d3LmJhaWR1LmNughB3d3cu
YmFpZHUuY29tLmNughJjbGljay5obS5iYWlkdS5jb22CEGxvZy5obS5iYWlkdS5j
b22CEGNtLnBvcy5iYWlkdS5jb22CEHduLnBvcy5iYWlkdS5jb22CFHVwZGF0ZS5w
YW4uYmFpZHUuY29tgg9tY3QueS5udW9taS5jb20wCQYDVR0TBAIwADAOBgNVHQ8B
Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGEGA1UdIARa
MFgwVgYGZ4EMAQICMEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb20v
Y3BzMCUGCCsGAQUFBwICMBkMF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMB8GA1Ud
IwQYMBaAFF9gz2GQVd+EQxSKYCqy9Xr0QxjvMCsGA1UdHwQkMCIwIKAeoByGGmh0
dHA6Ly9zcy5zeW1jYi5jb20vc3MuY3JsMFcGCCsGAQUFBwEBBEswSTAfBggrBgEF
BQcwAYYTaHR0cDovL3NzLnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL3Nz
LnN5bWNiLmNvbS9zcy5jcnQwggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEAdwDd6x0r
eg1PpiCLga2BaHB+Lo6dAdVciI09EcTNtuy+zAAAAVaQfkc6AAAEAwBIMEYCIQCT
LTzo3DYr1v3qgw30B/37GzgST+iXqZtWj1FjVrawzQIhAMxUeruo6bLLmlqsE4hW
YcDOu8hivJK4TefT1NDhb07DAHYApLkJkLQYWBSHuxOizGdwCjw1mAT5G9+443fN
DsgN3BAAAAFWkH5HWgAABAMARzBFAiAfRCG9WGKLQhLcPg5Dv+8MqUslHec5awM8
ahTB4Y0ddwIhAIzuy0JBUsTmk+Eg5ArobPqgXYFc1llXRceY4uTZiASZMA0GCSqG
SIb3DQEBCwUAA4IBAQBBLDatqFCdrwIrDoenQ7eCPpp1H0G9BvHI+5JAXQiI6Und
iSkaq7A9WvgAsVGNw1wGZIjysBQaf2VhJpbSFZwz9D9t3pmTAApVSY0uUvqiFg7X
NqDoqu3iyBBNw5hGzP/AzU2RoT1Sd7bf57xBEW5W1nxogMSE1ACNf/8WZwixZk5t
5RcW6zvGQiJ8+3OA+NA8tyUcGj1mhDBb7Z4yjbn8cily5DA34nXpiYXnHGic5TLn
QkaFIbZ9z7GqroE8oLrTUhOy+ZFNsrwanNO+gqf6c59V+1hQzRvkKN24JzdWjwHx
jsl/tY61DHvNFsmc683ggLjI+ZWMya1UcDmxADhN
-----END CERTIFICATE-----
subject=/C=CN/ST=beijing/L=beijing/O=BeiJing Baidu Netcom Science Technology Co., Ltd/OU=service operation department./CN=baidu.com
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4

No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits

SSL handshake has read 5095 bytes and written 373 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: AFDCCD740277C12869B7048831108C58C671098F1D74C22902F206C69F1DEB8E
Session-ID-ctx:
Master-Key: 820A0AEF1C20CF65C9BECB77EB819DCC5FCF1C034005403986A4365681FDFC929C814CA46B089AF08B7990E775948519
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 72000 (seconds)
TLS session ticket:
0000 - 41 cc a1 a4 d8 1d 10 00-9a f7 30 93 ec 4c 91 85 A.........0..L..
0010 - 60 bf c3 99 3a 15 29 33-ba 5f fa 8c 37 5e 75 05 ...:.)3._..7^u. 0020 - f0 5a 53 56 4f 39 13 d2-3d bc 2b b0 b8 3c ba af .ZSVO9..=.+..<.. 0030 - 0b ca 87 f8 da f4 e6 7e-03 4e 30 b8 33 14 11 61 .......~.N0.3..a 0040 - de 53 60 c8 77 d0 d2 75-75 c1 79 54 cd a8 29 5c .S.w..uu.yT..)
0050 - 01 cf f9 be 7a 65 b3 f7-00 a7 30 a1 80 55 b2 8b ....ze....0..U..
0060 - a9 20 e4 f3 63 ca 4c 9e-e8 44 92 ca 07 e7 4c 82 . ..c.L..D....L.
0070 - fc e9 b9 08 d7 b2 84 ee-2b e0 75 c9 a3 de 7e d3 ........+.u...~.
0080 - c3 1f 5d c2 ba 66 00 75-f9 8e 7d 74 3a 9c 5f fb ..]..f.u..}t:._.
0090 - 43 71 b4 aa 30 47 0d 95-2f 9f e8 17 8b 62 4c 7f Cq..0G../....bL.

Start Time: 1484794883
Timeout   : 300 (sec)
Verify return code: 0 (ok)

@dingmandmq

This comment has been minimized.

dingmandmq commented Apr 1, 2017

Me too facing same issues
Mitmproxy version: 2.0.0 (1.0.8dev0000-0xad8f288)
Python version: 3.5.1
Platform: Linux-2.6.32-642.13.1.el6.x86_64-x86_64-with-centos-6.8-Final
SSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Linux distro: CentOS 6.8 Final

And I try use mitmproxy --insecure to skip verification.It's also has errors

192.168.178.193:56178: CONNECT github.com:443
<< Cannot establish TLS with client (sni: github.com): TlsException("(-1, 'Unexpected EOF')",)

@hrchu

This comment has been minimized.

hrchu commented May 18, 2017

@kennytm 's comment should be add to the faq.

@yingshang

This comment has been minimized.

yingshang commented May 28, 2017

@kennytm
I try your idea,but i'm failure.
all https sites response error
httpSyntaxException('Bad HTTP request line: / HTTP/1.1',)

Mitmproxy version: 0.18.2
Python version: 2.7.5
Platform: Linux-3.10.0-514.16.1.el7.x86_64-x86_64-with-centos-7.3.1611-Core
SSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Linux distro: CentOS Linux 7.3.1611 Core
@yingshang

This comment has been minimized.

yingshang commented May 28, 2017

i use ubuntu 16.04 is normal,but centos is error

@mrdulin

This comment has been minimized.

mrdulin commented Jul 24, 2017

same issue.

@sryze

This comment has been minimized.

sryze commented Sep 15, 2017

I have the same problem on macOS Sierra. It happens when running my iOS app on the simulator and trying to access some API over HTTPS. But there are no errors when I simply browse the web in Chrome.

@pimlottc-gov

This comment has been minimized.

pimlottc-gov commented Nov 27, 2017

@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 openssl command line utility, at least not on my Mac)

@mhils

This comment has been minimized.

Member

mhils commented Nov 28, 2017

@pimlottc-gov: We use the Python certifi package (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.

@pimlottc-gov

This comment has been minimized.

pimlottc-gov commented Nov 29, 2017

@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 certifi package included within mitmproxy.

For my homebrew-installed copy of mitmproxy, I found the CA list at:

/usr/local/Cellar/mitmproxy/2.0.2_1//libexec/lib/python3.6/site-packages/certifi/cacert.pem

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment