[Bug]: Can't authenticate with x5c provisioner to step ca admin

[miguelangel-nubla]

Steps to Reproduce

pi@tinyca:~$ step ca admin list
No admin credentials found. You must login to execute admin commands.
✔ Please enter admin name/subject (e.g., name@example.com): step
✔ Provisioner: provisioner1 (X5C)
provisioner type 'X5C' requires the '--x5c-cert' flag
pi@tinyca:~$ step ca admin list --x5c-cert
Incorrect Usage: flag provided but not defined: -x5c-cert

Your Environment

• step CLI Version - 0.23.2

Expected Behavior

Authenticate using X5C credentials, as you can even create a Super Admin with that provisioner:

SUBJECT PROVISIONER     TYPE
step    admin (JWK)    SUPER_ADMIN
step    provisioner1 (X5C)      SUPER_ADMIN

Actual Behavior

throws:
provisioner type 'X5C' requires the '--x5c-cert' flag

Additional Context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[miguelangel-nubla]

Same happens with step ca token.
Is this by design?

[maraino]

cc @dopey

A workaround might be to create a certificate using that provisioner and then use it with --admin-cert and --admin-key

[dopey]

As @maraino mentioned, you can always just generate the certificate and key yourself - making sure to use the x5c provisioner and the exact subject name step. But, that is a workaround.

@miguelangel-nubla Can you tell us more about the use case, please? I'm struggling to come up with a reason for using an x5c provisioner to then provision an admin credential. If the goal is to authenticate to the admin API using an "identity" certificate (let's say one issued to a user or something like that), then using --admin-cert and --admin-key would be our recommended approach.

If we find that using the --admin-cert and --admin-key flags is suitable for use cases like yours we may want to remove the ability to add X5C admin provisioners since it's confusing and not recommended.

[miguelangel-nubla]

The use case is using hardware signing (yubikey or pkcs11) for as much as possible, as to not have the chance of a private key or passphrase leaking.

The ability to use a --x5c-cert and --x5c-key together with --kms to authenticate to a provisioner reduces the attack vector considerably. An attacker with full access to your system will be limited to the actions you have signed (ideally with the touch of the yubikey), nothing more, instead of full access to the scope of the provisioner.

It just works already with ssh certificates:

step ssh certificate \
--kms "yubikey:?pin-value=123456" \
--x5c-cert "yubikey:slot-id=85" \
--x5c-key "yubikey:slot-id=85" \
--provisioner provisioner1  user

which I think is awesome.

Would love to see support for it everywhere, other more useful examples that come to mind are step ca token and step ssh login with the touch of a button, and no higher level secrets at risk.

[maraino]

Same happens with step ca token.
Is this by design?

No, we want to support kms everywhere, but we need to dedicate time to do it, and we've only done it in the most commonly used commands.

Some time ago I created this script that you should be able to use with a YubiKey too.

Adding kms support for all the admin commands might be a bit hard, but adding it to step ca token and adding an --admin-token flag to the admin commands might be more manageable.

[dopey]

Ah, ok, that makes sense. If the cert/key are in a yubikey, then the admin middleware won't be able to correctly generate the necessary token.

We've created two new enhancements alongside this bug report -

1. Add --admin-token flag for step ca admin commands. #863 -- This will enable users to pass in a fully formed x5c token to authenticate to the admin API.
2. Add kms support to step ca token #862 -- This will enable users to generate a token using KMS.

Thanks for bringing the issue to our attention @miguelangel-nubla, and for explaining the use case.

[miguelangel-nubla]

Great, the token approach seems a good workaround until kms support is everywhere.

Some time ago I created this script that you should be able to use with a YubiKey too.

will definitely try that, thanks.

Thanks for bringing the issue to our attention @miguelangel-nubla, and for explaining the use case.

Thanks for making this open-source.

[maraino]

@miguelangel-nubla there's no need for the script, in master we now have support for --kms with step ca token. But adding it to the admin client it's not straightforward as adding an --admin-token flag, but I think we are close to solving it.