smallstep / certificates

🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.
https://smallstep.com/certificates
Apache License 2.0
6.8k stars 445 forks source link

[Bug]: command 'step ca provisioner list' returns an error #2012

Closed roblatour closed 1 month ago

roblatour commented 2 months ago

Steps to Reproduce

The command step ca provisioner list returns 'step ca provisioner list' requires the '--ca-url' flag

however, according to the documentation this command should work without that flag

ref:
https://smallstep.com/docs/step-ca/provisioners/#list-all-provisioners and https://smallstep.com/docs/step-cli/reference/ca/provisioner/index.html#description

Your Environment

Expected Behavior

return a list of provisioner

Actual Behavior

returns 'step ca provisioner list' requires the '--ca-url' 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).

dopey commented 1 month ago

Hey @roblatour 👋 - thanks for opening the issue.

step ca <cmd> commands use default configuration that gets stored in the $(step path) when you run step ca bootstrap --ca-url <ca-url> --fingerprint <fingerprint>. If the defaults have not been pulled down (via step ca bootstrap), then step ca <cmd> commands will prompt for the CA URL.

So, can you please try running step ca bootstrap --ca-url <ca-url> --fingerprint <fingerprint>, and then rerun step ca provisioner list.

roblatour commented 1 month ago

Thank you.

I got this error following the instructions at https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/

I had made it to the point in the above linked walkthrough where I needed to enter the command: sudo -u step step-ca /etc/step-ca/config/ca.json but it threw the following error, so I was trying to find the provisioners that were inplace so that perhaps I could figure out which one was being duplicated.

image

In any case, based on the use of the instructions at https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/

for the ca-url is this just going to be "tinyca.local" (without the quotes)?

Also, how can I find the needed fingerprint value (as I'm not sure which one is required)?

Thanks again.

hslatman commented 1 month ago

Hey @roblatour, if you're following the tutorial, the ca-url is https://tinyca.internal. It can be different for your environment if you configured the CA to run with a different DNS name or IP.

The fingerprint will be printed when the CA is started (successfully). In this case it seems that the CA is trying to load two provisioners with the same name. Check your ca.json for duplicate provisioner (names), and remove/rename the duplicate(s).

roblatour commented 1 month ago

Thank you

By tinyca.internal I assume perhaps you mean, tinyca.local (only because I cannot ping tinyca.internal but can ping tinyca.local)

Regardless, I tried both - but still get the same error. Here is my ca.json file, I don't see any duplicates?


{
        "root": "/etc/step-ca/certs/root_ca.crt",
        "federatedRoots": [],
        "crt": "/etc/step-ca/certs/intermediate_ca.crt",
        "key": "yubikey:slot-id=9c",
        "kms": {
            "type": "yubikey",
            "pin": "redacted"
        },
        "address": ":443",
        "insecureAddress": "",
        "dnsNames": [
                "https://tinyca.internal",
                "192.168.1.200"
        ],
        "logger": {
                "format": "text"
        },
        "db": {
                "type": "badgerv2",
                "dataSource": "/etc/step-ca/db",
                "badgerFileLoadingMode": ""
        },
        "authority": {
                "enableAdmin": true
        },
        "tls": {
                "cipherSuites": [
                        "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
                        "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
                ],
                "minVersion": 1.2,
                "maxVersion": 1.3,
                "renegotiation": false
        }
}
hslatman commented 1 month ago

Thank you

By tinyca.internal I assume perhaps you mean, tinyca.local (only because I cannot ping tinyca.internal but can ping tinyca.local)

My bad. Yes, that's it.

Regardless, I tried both - but still get the same error. Here is my ca.json file, I don't see any duplicates?


{
        "root": "/etc/step-ca/certs/root_ca.crt",
        "federatedRoots": [],
        "crt": "/etc/step-ca/certs/intermediate_ca.crt",
        "key": "yubikey:slot-id=9c",
        "kms": {
            "type": "yubikey",
            "pin": "redacted"
        },
        "address": ":443",
        "insecureAddress": "",
        "dnsNames": [
                "https://tinyca.internal",
                "192.168.1.200"
        ],
        "logger": {
                "format": "text"
        },
        "db": {
                "type": "badgerv2",
                "dataSource": "/etc/step-ca/db",
                "badgerFileLoadingMode": ""
        },
        "authority": {
                "enableAdmin": true
        },
        "tls": {
                "cipherSuites": [
                        "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
                        "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
                ],
                "minVersion": 1.2,
                "maxVersion": 1.3,
                "renegotiation": false
        }
}

It looks like your provisioners are stored in the database. Apparently the tutorial was updated to make use of that, as it's not the current default (i.e. --remote-management). It's surprising to me that it was even possible to create two provisioners with the same name, because I think we have a check for that.

The simplest way to get this fixed is to (re)move all of the existing files from ~/.step and to recreate your CA with the step ca init command. Alternatively you could create a new CA using --context, which will store files in a context specific directory, but you would still have the old files lingering around in that case. Considering that you're still setting things up, removing or overwriting the old files shouldn't break much on your side. Removing the provisioners from the database will be a little bit more involved because of the data types that are in use.

roblatour commented 1 month ago

ok - I'll take a fresh run at it when I can. Any idea when the tutorial might be updated?

Also, I don't want to be hi-jacking this issue. The original problem was more simply the command step ca provisioner list wasn't behaving as advertised in the doc.

Now that you know about that do you want me to close this issue, or leave it open?

hslatman commented 1 month ago

ok - I'll take a fresh run at it when I can. Any idea when the tutorial might be updated?

The tutorial was already updated. It didn't use the --remote-management option in the past (IIRC), but it does these days.

Also, I don't want to be hi-jacking this issue. The original problem was more simply the command step ca provisioner list wasn't behaving as advertised in the doc.

Now that you know about that do you want me to close this issue, or leave it open?

I think after recreating the CA you'll have it running correctly, and after bootstrapping with the CA, you shouldn't be getting the ca-url error. If that's the case, then you can close this issue.

roblatour commented 1 month ago

Well, I simply cleared out everything and redid it all from the beginning.

It all worked, up until the end. The service comes up started when I boot the Raspberry, stops (becomes inactive) when I unplug the yubikey, but does not restart when I plug the yubikey back in.

In the service definition file I tried changing ExecStart=/bin/sh -c '/usr/local/bin/step-ca /etc/step-ca/config/ca.json' to ExecStart=/usr/local/bin/step-ca /etc/step-ca/config/ca.json for simplicity, but that didn't help

hslatman commented 1 month ago

You might be using a different model, for which you may need different udev rules: https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/#configure-systemd-to-start-the-ca

roblatour commented 1 month ago

i am using a YubiKey 5 NFC;

image

roblatour commented 1 month ago

also, for what its worth - here is the output of
journalctl -xe

at 11:36 I pulled out the YubiKey - and it disconnected as expected at 11:37 I plugged in the YubiKey - it looks like it recognized that, but failed to start the service

image

here is some other related info: image image

hslatman commented 1 month ago

@roblatour I'm closing this issue, as the original problem was resolved. You can create a new issue for the YubiKey insertion/ejection flow if you want.