certificates
certificates copied to clipboard
SSH KRL Allow revocation by SSH Public Key
What would you like to be added
ssh-keygen allows manual key revocation by specifying a public key, such as
ssh-keygen -s /opt/ssh-ca/ca.pub -k -f /opt/rpt-ansible/etc/ssh/revoked_keys /opt/VMTools/public-keys/old/retired/* /opt/VMTools/public-keys/old/processed/*
Why this is needed
When I need to revoke somebodies access I don't want to track down every cert they issued, I want them all revoked, so I need a KRL that I can push to all our jumpservers. Being able to ban a key completely is critical to the CA operation.
I might take a crack at this, the current things stopping this are:
- When a new SSH cert is issued,
StoreSSHCertificate()stores it against the serial number insshCertsTable, and it also stores the serial insshUsersTableagainst all the principals in the cert; We want to be able to revoke all certificates that have been issued to a user, so we need to add a way of tracking users old certificates, as it stands at the moment i think the only way to do that would be to enumerate all the certificates and look for a user in principals or keyid, which is likely to take a long time - A new https endpoint needs to be created to list all revoked ssh certificates, probably in the format OpenSSH expects for
RevokedKeys - A new API endpoint might need to be created to allow revocation by KeyID/Username, or alternatively when revoking a user certificate, the revoke endpoint could examine the ssh cert, extract the KeyID and then revoke all certificates that have the same KeyID? Im unsure about all the use cases so revoking all user certs that match the KeyID might be undesirable for some scenarios
Perhaps @maraino or @mmalone could comment on whether these are acceptable actions before I start hacking away?
https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.krl indicates there is 2.4. Revoked key ID sections which may mean the key-ids DONT need to be stored with step, and we can just add methods to invalidate a key or host...
Hey @unreality 👋 . I would hold off on implementing this just yet. As mentioned in a few other PRs, we are planning to release a plugin or web-hook style architecture that would allow users to "attach" additional functionality without it living in the step-ca codebase.
This feature would be a great use case once that architecture becomes available.