Certificate Revocation List (CRL) support with https

Currently requests doesn't support checking if a certificate has been revokes in a CRL when using verify=True, it would be quite useful if this was supported.


Have you encountered a certificate that should have been revoked which wasn't? I'm 90% sure that Kenneth curates the list carefully to remove revoked certs.


We have a new policy thanks to the security-conscious guys handling Requests' integration with `pip`. Each release we update our list of certs, which includes removing any that have been revoked.

Now, obviously this is not perfect: if for any reason you can't update Requests you have to do this yourself, and there's also a delay of a month or so (usually) between releases. So that's a bit lame.

The much bigger problem is that this is not easy to do in a user-friendly way. To consult a CRL the user would have to tell us which CRL to look at. These CRLs can be provided in a number of ways (IIRC the standard already suggests WebDAV and HTTP, and flat files are possible as well). In practice, we'd either have to hardcode _all_ the possible CRLs, or resort to an API where the user provides the location of the CRL they'd like us to consult. That API is pretty brittle, frankly.

I'd be happy to have this if we could think of a decent API for it, but I just don't think we can. Given that it's also not a widely-requested feature, it's probably going to be best to ask that users who are worried about it curate their own certificate lists.


On Fri, 06 Dec 2013 23:13:10 -0800

> I'd be happy to have this if we could think of a decent API for it,
> but I just don't think we can. Given that it's also not a
> widely-requested feature, it's probably going to be best to ask that
> users who are worried about it curate their own certificate lists.

I am mostly concerned about using this internally, we have our own
certificate management system, and we do publish CRLs for our internal
certificates, this will allow us to have requests fully integrate into
our internal certificate system.

For my usage, being able to specify a file or set of files to read the
CRL from would be quite sufficient, maybe along the lines of how a
particular client cert is specified.


So are you providing a custom certfile anyway? If so, it seems like the best thing to do is to handle this outside Requests: obtain and parse the CRL, apply the changes to the certfile before passing it to Requests. I just don't think this feature would be widely-used enough to make it worth the pain.


I think this is a problem with OpenSSL (or perhaps just Python's implementation of it), not Requests. 

I would recommend setting up your own CA bundle and just providing that. with the `CURL_CA_BUNDLE` environment variable, or similar. 


On a slightly tangential point: Is requests still under a feature freeze?


Yes, but policies are never without exceptions.


The cert bundle won't work as we have a single CA cert and accept any cert signed by our CA cert and not in the CRL (occasionally with some CN restrictions), so doing processing outside of requests doesn't really work for us (I suspect this is a fairly common use case, I know there are lots of companies that use this internally).


Thanks for the feedback.


I am also interested by this feature. When using an internal CA, the CRL as a file is the easiest path. Far easier than using an OCSP endpoint and more reliable than embedding an HTTP URL into the certificate (no way that the CRL can be unavailable due to a temporary outage).

@Lukasa I don't understand when you say this can be done outside requests. There is no way to preprocess the certfile with the CRL. The certfile is usually a root certificate and the CRL contains the serial numbers of revoked certificates. There is no way to apply a CRL to a root certificate.

With curl, you can specify it with `--crlfile`.


@vincentbernat Yeah, that's a fair point.

We're aiming to add support for providing an external SSLContext object, which should make this possible, but until that's done I don't think we can do much else.


Plus one for this feature request for use with an internal CA.