Mozilla's list also includes distrusted certificates, so you need to be careful to leave them out when generating the PEM-encoded format. In fact, I'd strongly recommend using Adam Langley's excellent extract-nss-root-certs tool [2] which takes care of the subtle details for you.
And, if you are willing to trust me, you can download my pre-generated PEM-encoded cacerts file from a month or so ago [3].
[1] https://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw...
[2] https://github.com/agl/extract-nss-root-certs
[3] https://github.com/downloads/tav/ampify/distfile.cacerts-201...
However, given that it's what we currently have, I'd strongly advice taking advantage of the security that it provides. Requiring API client library authors to ship certs will make for poor security. Not only do certificates expire, they also get compromised.
It would be easy to conduct MITM attacks using revoked certs and API client library users would be none-the-wiser. Instead, it should be the responsibility of HTTPS client libraries to use the latest cacerts data and support features like OCSP [1] for validating certificate revocations, etc.
[1] http://en.wikipedia.org/wiki/Online_Certificate_Status_Proto...
So if you try to validate that the certificate is the specific one that your API server is using, it's going to fail in that scenario.
Depending on your app, you could just ignore that possibility of course.
There's a Perl-language converter tool available there, for those that don't have Go handy for the extract-nss-root-certs tool.
And there's also a shell script there that uses the certutil tool [2] that can be used to extract the Firefox certificate store.
[1] http://curl.haxx.se/docs/caextract.html
[2] http://www.mozilla.org/projects/security/pki/nss/release_not...
If you're doing anything serious with Python and SSL, you're going to use M2Crypto - period. Because when it comes to security, the less you "roll your own", the better.
[1] http://chandlerproject.org/Projects/MeTooCrypto
[2] http://svn.osafoundation.org/m2crypto/trunk/demo/x509/certda...
This is exactly the problem that https://github.com/agl/extract-nss-root-certs was written to solve. I'd strongly recommend using it.
Or just serve your app/API/etc from different urls, plain HTTP for development and HTTPS for preprod and production.
Security is something that should just work - arguably, the first thing with such requirement. Even though it simply can't just work in many cases, it should be as close to just-working as it can.
http://docs.python.org/library/ssl.html#functions-constants-...
http://docs.python.org/library/ssl.html#ssl-certificates
However, this isn't exposed in the higher-level httplib.HTTPSConnection class for some reason. I'd bet it's not too hard to write your own subclass to handle it though.
Importing a new certificate is documented here: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security10.htm...
The verification of the certificate is delegated to a TrustManager[1]. Certificate paths can be checked[2] and the TrustManager is flexible enough to support a large variety of verification scenarios[3].
[1] http://docs.oracle.com/javase/1.4.2/docs/api/javax/net/ssl/T...
[2] http://www.exampledepot.com/egs/java.security.cert/ValidCert...
[3] http://stackoverflow.com/questions/11681474/how-can-i-trust-...
>>> requests.get('https://exmaple.com, verify=True) requests.exceptions.SSLError: hostname 'exmaple.com' doesn't match either of '*.exmaple.org', 'exmaple.org'
docs.python-requests.org/en/latest/user/advanced/#advanced
however, encrypted connection without this checks allows, for example, Man-In-The-Middle attack
So unless you really understand you app's deployment scenario well, you should proceed with caution. Also note that 2% of enterprise IT people understand SSL at all, (and the devices that do the MITM part are usually controlled by the security dept) so troubleshooting will be close to impossible.
* cert: Public x509 certificate to use. Default null.
[1] http://nodejs.org/docs/latest/api/https.html#https_https_req...
Same for the JRockit JVM.
That said ... it really only tells you that a certificate is 'sound'. It by no means tells you with 100% confidence that you are talking to the right party.
SSL/TLS is still pretty fragile.
With all the languages that support this by default, I'm surprised Python doesn't.
However, I don't know anything about using nginx that way. If you give me a link or something like that, I'll happily add it to my article. Or I'll just investigate later.
