CRL Issuing Distribution Point (IDP) should be configurable in CertificateRevocationListView

[kevin-olbrich]

Using the current release (1.21.0), it is not possible to remove the Issuing Distribution Point (IDP) from the CRL.

The docs seem to be outdated as the workaround in

django-ca/ca/django_ca/models.py

Lines 1092 to 1096 in e4bd073

	full_name : list of :py:class:`~cg:cryptography.x509.GeneralName`, optional
	List of general names to use in the Issuing Distribution Point extension. If not passed, use
	``crl_url`` if set.
	relative_name : :py:class:`~cg:cryptography.x509.RelativeDistinguishedName`, optional
	Used in Issuing Distribution Point extension, retrieve the CRL relative to the issuer.

no longer works because of a choice made in

django-ca/ca/django_ca/models.py

Lines 1164 to 1170 in e4bd073

	add_idp = (
	only_contains_attribute_certs
	or only_contains_user_certs
	or only_contains_ca_certs
	or parsed_full_name
	or relative_name
	)

Following the code path, there is no case where setting one of the above options, could prevent the addition of the IDP. The decision is made based on other attributes.

Use case:
I'm using an OpenVPN (via OpenSSL) server, which validates the IDP if it is present in the CRL. In this simple setup, there are no intermediate CAs and certificates are signed directly by the root CA. OpenVPN is unable to validate the CRL against the CA, as the CA does not match the IDP. For this setup it is sufficient to check the CRL signature against the CA without an IDP.

Possible solution:
Adding a new setting to CertificateRevocationListView just like "expires" would allow the user to define a custom CRL endpoint which skips the IDP. This does not break the default behaviour and makes CertificateRevocationListView more flexible.

Reference:
This is related to #64 (comment).

[mathiasertl]

Hi @kevin-olbrich,

Thanks of course for your report! I will add flag like this to the view and to the dump_crl command, allowing you to create CRLs without an IDP.

Can I ask you for more information so that I can reproduce this? In #64 and other issues I did add test cases to make sure that the use case is covered. To do the same here, I of course need to be able to reproduce this. (and who knows, maybe I can even help you improve your OpenVPN configuration ;-))

kr, Mat

[mathiasertl]

@kevin-olbrich, while starting to look into this, I discovered that it is currently indeed possible to create a view that does not include the extension: All you have to do is set the scope of the view to None, e.g.

views.CertificateRevocationListView.as_view(scope=None)

When using the dump_crl command, you should get a similar outcome if you simply don't pass the --scope parameter.

I will however still add a flag for this, as this extension certainly caused trouble in the past.

[mathiasertl]

(The current commit just adds a flag to the dump_crl command, the view is still missing)

[mathiasertl]

This time fixed for real! Feature is implemented and will be included in the next release!

However, I'm still hoping for more input so that I can reproduce your setup in automated tests.

[kevin-olbrich]

However, I'm still hoping for more input so that I can reproduce your setup in automated tests.

Actually it is not very complicated. I created a root CA on CLI (without intermediaries). I then copied the CA cert available via URL to the OpenVPN server. When I added crl-verify for OpenVPN (crl is downloaded using cron), it always failed when connecting with a valid certificate. Actually it is related to the problem in #64.

OpenVPN validates the IDP using OpenSSL if it is present in the CRL. At least for me, it was not present or did not match in the root certificate and thus failed verification.

As the download happens in the background and blocking all connections because of an error in validation is not an option, it was better to remove the IDP extension from the CRL. In case OpenVPN would get a CRL that matches the CA but not the IDP, OpenVPN could not do anything to solve this (which IMHO is a minor issue with large consequences).

Sorry, my knowledge of certificate extensions is limited. This is the first time I work with more complex setups in x509. I was only using easyrsa before, which simply brings it down to only basic features of x509.

Thank you very much for your time and help! I could not contribute much to this change, the more I want to thank you for implementing everything!

[mathiasertl]

Hi Kevin,

Sorry, my knowledge of certificate extensions is limited. This is the first time I work with more complex setups in x509. I was only using easyrsa before, which simply brings it down to only basic features of x509.

No worries, that's what the author of such a software is here for. I'm glad I can help.

Actually it is not very complicated. ...

Can you please post the relevant configuration snippets from OpenVPN, client- and server side? Of course, please properly sanitize it and don't post private keys ;-). also are you downloading the client- or server CRL? I assume the former, but just to be sure (you can answer that question by posting the URL path, if you use a default provided view, or together with the view configuration).

Thanks very much for reporting the issue and for using django-ca!

kr, Mat

[mathiasertl]

closing due to lack of feedback. If you have any further issues @kevin-olbrich , please don't hesitate to file a new issue!