Closed mplonka closed 7 years ago
The PEM file actually comes from https://mkcert.org/generate/. I see no reason to remove the comments on the source side, given that every other tool is happy to ignore them. But I also see no reason we shouldn't fix up the build process for certifi to strip them.
I consider this an issue on certifi more than on requests, so I've opened certifi/python-certifi#50, which tracks the work.
Thanks for the report!
Hi @Lukasa. Thanks for looking into that. Wouldn't it be wise to do some sort of escaping of those comments in https://github.com/Lukasa/mkcert itself? Are you OK with me submitting a PR there?
@mplonka I don't really see any reason to do the escaping there. PEM isn't well specced but so far we have only one extremely unusual implementation that chokes. I don't really see any reason to destroy that output for that, given that it's clearly intended to be human readable.
When using requests with Jython running on of IBM JVM, accessing HTTPS endpoints fails with:
Example code:
The problem occurs only with Jython and only when running on IBM JVMs. The exception is being thrown by IBM's implementation of
java.security.cert.CertificateFactory
:It turns out that CertificateFactory in IBM JVMs is very strict when parsing PEM files and it does not allow non-ASCII characters at all, even in comments. After removing the following lines, everything works without issues:
A temporary workaround is to remove all comments from
cacerts.pem
file and setREQUESTS_CA_BUNDLE
variable:From what I can see in the Makefile, the
requests/cacert.pem
file is being downloaded from http://ci.kennethreitz.org/job/ca-bundle/lastSuccessfulBuild/artifact/cacerts.pem, which means that the patch should be either applied to that Jenkins job or theMakefile
. Not sure which one is best?My suggested solution (but not necessarily the implementation) is to encode those special characters with 'backslashreplace'. Piping the pem file through this script does exactly that: