feature request: ssh certificate revocation list

[OferE]

Feature Request:
Please add support for generating revocation list for SSH certificates.
Currently I need to manually keep track of all the certificates I signed using vault and generate a revocation list manually. Would be great if this can be supported by vault itself.
Thanks!

[jefferai]

We generally recommend making certificate lifetimes useful for only a single connection. As a result CRLs are unnecessary. This workflow can be made easier using vault ssh.

[OferE]

This is too strict for development accounts. The bureaucracy of creating new certificate every time is too much.
(BTW I opended a ticket in terraform for not supporting connections with certificates).

For production accounts it's reasonable.

[jefferai]

Isn't it the same workflow?

[OferE]

I'm not sure what do you mean by workflow.
We use ssh certifictaes to grant permissions to real human users not for automation/services.

Our product is in development mode and still not in production.
For development clusters I prefer to work with long living certificates. For production we will issue short living certificates.

[jefferai]

What I mean is, if you use vault ssh to connect (or a custom script that does essentially the same thing), whether the certificates are short lived or long lived makes very little difference.

[johndistasio]

That workflow is predicated on the Vault cluster being available and reachable for vault ssh, no? If I'm using certificates for SSH, there is probably a good chance I'm doing it to avoid a dependency on some separate authentication infrastructure during an emergency.

It would be nice to distribute a CRL with Consul Template or similar.

+1 for this feature request.

[kogent]

I would agree that there are some use cases where longer ttls is appropriate. Being able to revoke those would be very welcome.

Also not every tool is able to leverage vault ssh.

[kenrestivo-stem]

We have a use case where we need:

1. Long-lived connections and client SSH keys
2. Only SSH protocol/port is available from the client; there is no connection to Vault
3. Ability to revoke keys on a key-by-key basis

I don't see a way to do this with Vault CA (which isn't really a CA as there's no CRL and the host doesn't check) or OTP (which requires that the client be able to reach Vault in order to fetch its OTP, nor do I see a way to revoke its access on a client-by-client basis either)

[tq05]

Any update on this.
Seems like quite a fundamental functionality to have if you start supporting ssh ca and play in this world as well.

Makes a hard sell against other technologies otherwise

[nafpliot]

I also find this a really nice to have feature. If revocation cannot be done, we should at least have a way to list all the certificates that are signed. It's easy to lose track if you work with long living certificates...

[adambaumeister]

+1. The idea of short-lived certificates makes good sense but pkey auth is widely used for many other applications where it's not applicable.

Revocation or at least an index of signed certificates would be a great feature to be built into the workflow.

[jefferai]

The idea of short-lived certificates makes good sense but pkey auth is widely used for many other applications where it's not applicable.

Can you give us examples of these applications/use-cases? It seems like you're better off in the end making some wrapping around those to use short-lived certificates than using long-lived ones.

Storing lists of issued certificates in Vault is relatively expensive, especially when they're very short term, causing a lot of storage churn. I should note however that you don't need Vault specifically to generate a KRL for you. KRLs are unsigned (AFAICT) so anyone can generate one at any time.

[adambaumeister]

@jefferai

Can be summarized as any case where:

• The vault server is not reachable from the client
• Wrapper code or binaries are undesirable

A practical example would be the classic (and ubiquitous) SSH proxy server, another would be standalone cloud deployments where the password vault is on-prem.

It's a chicken and egg thing with the KRL as well, without any storage on the Vault side I don't have the pkeys to build the list.

A simple solution might be an option somewhere to not hash the pkey when sent to the audit plugin.

[jefferai]

You can already not hash values sent to audit. See https://www.vaultproject.io/api/system/mounts.html#audit_non_hmac_response_keys-1

[jefferai]

Although I'd opt out of hashing the serial number rather than the private key.