Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: ssh certificate revocation list #3377

Open
OferE opened this Issue Sep 26, 2017 · 17 comments

Comments

Projects
None yet
8 participants
@OferE
Copy link

OferE commented Sep 26, 2017

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

This comment has been minimized.

Copy link
Member

jefferai commented Sep 26, 2017

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 comment has been minimized.

Copy link
Author

OferE commented Sep 26, 2017

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

This comment has been minimized.

Copy link
Member

jefferai commented Sep 26, 2017

Isn't it the same workflow?

@OferE

This comment has been minimized.

Copy link
Author

OferE commented Sep 27, 2017

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

This comment has been minimized.

Copy link
Member

jefferai commented Nov 30, 2017

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

This comment has been minimized.

Copy link

johndistasio commented Dec 28, 2017

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

This comment has been minimized.

Copy link

kogent commented Mar 1, 2018

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

This comment has been minimized.

Copy link

kenrestivo-stem commented Mar 12, 2018

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

This comment has been minimized.

Copy link

tq05 commented Jul 29, 2018

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

This comment has been minimized.

Copy link

nafpliot commented Aug 6, 2018

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

This comment has been minimized.

Copy link

adambaumeister commented Aug 7, 2018

+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

This comment has been minimized.

Copy link
Member

jefferai commented Aug 8, 2018

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

This comment has been minimized.

Copy link

adambaumeister commented Aug 8, 2018

@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

This comment has been minimized.

Copy link
Member

jefferai commented Aug 9, 2018

@jefferai

This comment has been minimized.

Copy link
Member

jefferai commented Aug 9, 2018

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

@adambaumeister

This comment has been minimized.

Copy link

adambaumeister commented Aug 9, 2018

As far as I know there is no method to route individual secrets backends to a specific audit method which means youd be turning of hashing within auditing altogether, which wouldn't be so good. I could be wrong?

@jefferai

This comment has been minimized.

Copy link
Member

jefferai commented Aug 9, 2018

Setting that would turn off hashing the serial number for that particular mount for all audit methods, yes. But serial numbers are not generally sensitive anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.