On 19/10/2017 17:40, Gregory Szorc wrote:
CERTIFICATE_VERIFY_FAILED likely means there is no trust chain on the
client for the server x509 certificate. My guess is the Amazon root CA
isn't in the trusted root CA certificates list on that Windows builder. You
can verify this by temporarily disabling x509 certificate trust checking
via ssl.wrap_socket(cert_reqs=ssl.VERIFY_NONE) (<2.7.9) or
ssl.SSLContext.verify_mode = ssl.VERIFY_NONE.
I know Firefox CI has had problems related to the Amazon root CA not being
installed because it is a relatively recent root CA.
The generic Python way to fix this is to use the certifi Python package and
load it by specifying ca_file to ssl.wrap_socket() (pre 2.7.9) or
ssl.SSLContext.load_verify_locations() with 2.7.9+. Or figure out where
Python thinks the default CA certificate list is
(ssl.get_default_verify_paths()) and ensure a modern root CA bundle is in
that location. Although on Windows and MacOS, support for loading certs
from the system varies. Read the code comments at
https://www.mercurial-scm.org/repo/hg/file/aa5e7b4a3a01/mercurial/sslutil.py#l693.
Also note the hack on MacOS's Python where loading a specially crafted CA
file has the side-effect of importing CA certs from the MacOS Keychain.
Talk about an esoteric hack!
Thanks, with this advice I’ve managed to land
https://github.com/servo/servo/pull/18942
However the cafile parameter of urllib2.urlopen() is new in 2.7.9 and I
don’t know how to feature-test that without making a call and catching
some exceptions, but that seems fragile. We’re not using the ssl module
directly.
So now, `if HAS_SNI and sys.version_info >= (2, 7, 9)`, we use the
CloudFront hostname with root CAs from the certifi package. Otherwise we
use the unofficial S3 hostname.
--
Simon Sapin
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
