API endpoint that checks the CRL for a given cert serial number - for an automated renewal process

[jonathanalexander229]

Is your feature request related to a problem? Please describe.
We are designing an automated certificate renewal process, and after researching there does not appear to be a method or endpoint that will check the pki crl for a certificate. This means we must manually pull down the CRL and use Openssl or other methods to check if the cert in question is part of the CRL.

Describe the solution you'd like
An end point that we could POST the certs serial number to and receive a response if it is part of the CRL

Describe alternatives you've considered
Within our ansible playbook I am attempting to pulling down the CRL from the v1/pki/crl/pem endpoint, then use 'community.crypto.x509_crl_info' to parse the CRL, then check if the cert in question serial number is part of that list.

Explain any additional use-cases
Automated certificate check/renewal process. In addition to checking that the cert is still valid, we also should check if the cert if part of the CRL, and if so it should be renewed/regenerated

[hsimon-hashicorp]

Hi @jonathanalexander229! We will bring this up to our product managers to discuss this feature request. Overall, CRLs may be clunky and grow overly large, so it will require some careful thought. Thanks for sending this request in. :)

[ixe013]

I'm afraid you are confusing expiry and revocation. An expired certificate will not appear in the CRL. If the endpoint you suggest existed, your certificate would never be in it.

To have a certificate show up in the CRL, you must explicitely revoke it. For example, if you think your private key was compromised, you would revoke your certificate and ask for a new one right away. Again, if that endpoint existed there would be no point querying it because you would know your certificate is in it - you just revoked it yourself!

There is nothing wrong with having two certificates valid at a given point in time (say, when you run your playbook). That's renewal.

If your certificate is in a file called tls.crt, you can use openssl to know if it is about to expire in the next N seconds. For 24h, that number is 60*60*24=86400

openssl x509 -in tls.crt -checkend 86400

If the command succeeds, the certificate is still valid for another 24h. If it fails, call Vautl to get a new certificate.

[jonathanalexander229]

@ixe013 while I initially had the confusion, when I wrote this enhancement request I fully understood that the CRL will not contain expired certificates, and if expired they cannot be revoked. I am well aware how to check if a certificate is expired but thank you for the suggestion.

This enhancement is purely just a request to make CRL checking to be done on the backend, with a user provided certificate serial number.

For now we have to pull down the full CRL and manually parse each serial and check if the certificate serial number in question exists. Seems like a good feature to have and will prevent issues that may arise from manually pulling down and checking the serials programmatically.

[ixe013]

Ah! More like implementing OCSP then...

As for the parsing, this works on my machine (replace tls.crt with the name of your certificate file):

curl -s $VAULT_ADDR/v1/pki/crl | openssl crl -inform der -noout -text | grep $(openssl x509 -in tls.crt -noout -serial | cut -d= -f2)

That one liner ask the question : "is this serial number in the list?". If the command fails, your certificate is not revoked. If it succeeds, your certificate is in the list.

[jonathanalexander229]

I have already written a playbook that does this, if you think it not necessary close the issue. Just trying to help you improve your product.

[ixe013]

Well I'm not an Hashicorp employee. Just a guy like you looking for something fun to code while it rains. An OCSP responder fits that definition, thanks.

[hsimon-hashicorp]

Hi everyone! Thank you for the spirited discussion. There are a lot of factors involved in CRLs and related features which would all need to be duly considered, including performance implications as well as the level of complexity and any unintended consequences. Where other workarounds exist, we always encourage our community to use those, but please rest assured that we in HashiCorp are always trying to consider ways to make our products friendlier and easier to use. We really appreciate your patience and consideration.

[cipherboy]

\o hello @jonathanalexander229 -- #16723 has been included in the main branch for release -- as @ixe013 mentioned above, OCSP is the industry standard mechanism for this an is now included in Vault.

Let us know what you think!