PKI: automatic renewal of CRL

[jsfrerot]

Is your feature request related to a problem? Please describe.
Vault doesn't update the CRL next update date if you haven't revoked a certificate or issued a rotate-crls.
There was a ticket opened for this: #3827 but has been closed mentionning to use the rotate-crls api endpoint.
This becomes a PITA when you actually use the CRL feature and monitor the CRL. If the dates are not updated there is no way to be sure that the CRL is still valid. When investigating why my certificat check was failing, I first though there was a problem with vault because the CRL hasn't been updated.
Having to setup a cron to call the rotate-crls endpoint to renew the CRL is also not a good solution as it requires a sysadmin to setup the cron everytime you create/delete a CA/INT-CA.

https://www.ietf.org/rfc/rfc3280.txt says:

CRL issuers SHOULD issue CRLs with a nextUpdate time equal to or later than all previous CRLs

It shoud, but vault doesn't. It does not say this is it optional, is says that this is the best pratice... even though this is not mandatory.

also:

The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.

This means that it is not allowed to issue the CRL after the indicated data (next update). So vault should make sure to renew this automatically.

In a world that we try to automate things as much as possible, this is, I think, one that should be.

Describe the solution you'd like
automatically regenerate CRL before the "next update" value is going to expire.

Describe alternatives you've considered
At the moment, we use crons, but this is error prone when someone create/delete a new CA/INT-CA. The chance of not adding/removing the cron for this change is high.
You also need a token to make the rotate call, which is ok, but complicates things when havving to do this as a cron.

Thank you for considering this.

[oxlade39]

+1 on this. We are using certvalidator to check the validity of the cert chain and it fails on this line. It seems like vault should automatically refresh this.

[mbeiter]

+1 as well.

This here is the crucial part in the RFC:

The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.

I understand why Vault does not want to guarantee this with a scheduled job, but at the same time it is impractical to trigger that from outside of Vault. It would require knowledge on the mount structure to automate this, and appropriate access rights.

This cannot be trivially done, specifically in a multi-namespace setup.

[HridoyRoy]

Hi all,
Thanks for your patience. I'll take a look at this and circle back with some feedback.

[megalithSE]

+1
I have started a internal PKI setup. That are a mix of CA's and clients. As Windows really wants to check CRL for verification's on other CA's this are a burning issue to tackle. I'm looking at using Ansible AWX jobs for this. But aren't sure it will work optimal.
Also when you want an external CRL server to handle all CA's CRL, this is other scenario that becomes a problem.

Hope to see something for this soon!

[oliver-rew]

+1 as well.

This feature would greatly simplify automated deployments

[Dvergatal]

+1 too
I would be grateful for having this feature

[ixe013]

I also need this. Might give it a shot with a pull request. Relates to issue #7801 and to issue #3190 (somewhat).

[heatherezell]

Hi folks - thanks for chiming in with your wish for this support. I'll add it to the list of issues we're tracking internally, and bring it up with product. Thanks again!

[matt-moses]

Thanks for looking into this. Any update from the product team on this? I agree that this is should be core functionality.

[Torkolis]

+1

[Torkolis]

Does anybody know how I can rotate CRL from command line? when I use
write /pki/crl/rotate
as in https://www.vaultproject.io/api-docs/secret/pki#rotate-crls
I get this:

[betalb]

@Torkolis rotate is GET operation, so use read instead https://www.vaultproject.io/api-docs/secret/pki#rotate-crls

[Torkolis]

ah that worked, thanks

[cipherboy]

\o hello everyone! This has been done in #16762 -- control over the grace period before CRL expiration has been done.

Notably, this now pushes nearly all revocations to use automatic rebuilding, so there will be a delay between when the cert is revoked and when it appears on the next CRL. #16773 solves this via enabling light-weight delta CRLs which augment the last complete CRL and #16723 solves this by adding an OCSP responder which allows for live revocation status queries in the standard OCSP format.