Closed roblatour closed 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
.
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.
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.
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).
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
}
}
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.
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?
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.
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
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
i am using a YubiKey 5 NFC;
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
here is some other related info:
@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.
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
step-ca
Version - 0.27.4Expected 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).