PKI tidy didn't remove revoked certificates

Vault
1

Hi,

I’m trying to permanently delete expired and/or revoked certificates from vault but can’t succeed.

I config the tidy with the
vault write pki_int/tidy tidy_cert_store=true tidy_revoked_certs=true safety_buffer=“1h” command,
but after 1 hour, when I still list all the certificates, the revoke certificates still appear.

and When I call the following command as GET with the api call, it gives an “unsupported path” error.
https://Vault_ADDR:PORT/v1/pki/tidy-status

How can I solve this problem. Can you help me?

vault version: 1.9.4

2

This and/or is very important - which is the case?

If a certificate is revoked AND expired, it can be removed by tidy.

If a certificate is revoked BUT NOT expired, it is not a candidate for tidying, as it will be needed to build the CRL.

3

According to the earlier part of your message, your PKI secrets engine is mounted at pki_int not pki.

If this is the case, you should be using:

vault read pki_int/tidy-status
4

when i try i get the following output:

No value found at pki_int/tidy-status

my pki secret engines name: pki_int

5

@maxb First of all, thank you very much for your reply. How can I build the CRL only for revoked certificates?

6

Ah, I had overlooked that tidy-status is new in Vault 1.10.

In Vault 1.9 and earlier, you only get status feedback via a warning when you request to start the tidy, which says either:

  • "Tidy operation successfully started. Any information from the operation will be printed to Vault's server logs."

or:

  • "Tidy operation already in progress."

And then any problems showing up as warnings or errors in the Vault server’s error log.

This is always the case. The CRLs Vault generates always only contain revoked certificates.

7

so in summary, is there any way to delete a revoked certificate unless it expires from the certificate list under pki_int in versions after vault 1.10.0?

8

The short answer is no, there is not.

It is a rather unfortunate operational oversight.

You don’t mention why you’re trying to do this, but based on my own experience, I can guess that perhaps someone has issued a crazy amount of certificates and drastically increased the size of your Vault data store, and you’re trying to reduce it?

The only option available in Vault today, would be to enable the sys/raw endpoint, and perform manual surgery on the internal data store of the PKI secrets engine. You could try this if you really feel you need to, but I have not tested it in this use case, and cannot vouch for its safety.

If you do, be sure to write your ACL policies so you don’t accidentally enable reading the CA’s private key out of Vault via the sys/raw API!

9

The underlying problem is that if a certificate is just “deleted” rather than being included in the CRL then the cert is still actually valid.

Once a certificate has been issued the issuing system no longer has any direct control over that certificate - the issuer has just signed it with a trust statement saying that it will be valid as trusted between two dates. Without CRLs there is then no way to revoke that validity.

The CRL mechanism was created to try to fill that hole. If a certificate is listed in the CRL, and the user checks the CRL list (not all software may be configured to do so, or firewalls might prevent access) even though the certificate itself is still shown as being valid it will be seen as invalid.

If it is 100% certain that all references to a certificate have been destroyed (i.e. the key/cert/pem files have been removed with no copies or backups remaining) then a CRL entry isn’t actually needed - there is no way for the cert to be presented as all copies are gone.

However the more normal situation is that it can’t be assumed to be the case. Maybe there was a security exploit, so the certificate could have been copied elsewhere, or the certificate is being revoked because it was issued in error or against policy (with no knowledge of where the cert files exist). In this case an entry in the CRL is vital.

Once the certificate reaches its natural expiry the CRL entry can be removed as it is no longer needed.

In general with the usage of Vault you’d expect certificate validity periods to be fairly short. It is good practice to have short lived credentials which are then automatically rotated instead of using long lived ones - this is true for all the secrets that Vault can manage, be it IAM users, database credentials or PKI. If that is followed the overhead for keeping revoked certificates around (maybe for a few weeks/months at most) in the CRL should be minimal.

2 Likes