Bug 258827 - security/step-certificates: step-ca fails to start in the init process included SSH certs
Summary: security/step-certificates: step-ca fails to start in the init process includ...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL: https://www.freshports.org/security/s...
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2021-10-01 04:51 UTC by Adam Jimerson
Modified: 2023-09-17 04:22 UTC (History)
2 users (show)

See Also:
mw: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Jimerson 2021-10-01 04:51:06 UTC
After installing security/step-certificates 0.17.2, I noticed that the default step-ca rc script didn't include the "--ssh" flag to also have it generate SSH certificate authority files as well.

After editing /usr/local/etc/rc.d/step-ca and adding "--ssh" to the "/usr/local/bin/step ca init" line, and running service step-ca start I am able to get through the init process and it successfully generates the files under /usr/local/etc/step with a couple of issues.

> Generating root certificate... done!
> Generating intermediate certificate... done!
> Generating user and host SSH certificate signing keys... done!
>
✔ Root certificate: /usr/local/etc/step/ca/certs/root_ca.crt
✔ Root private key: /usr/local/etc/step/ca/secrets/root_ca_key
✔ Root fingerprint: 0e2c650bc2dec4e62d47bdf7dac269a2b046d97c98844fea62bc969bacc36057
✔ Intermediate certificate: /usr/local/etc/step/ca/certs/intermediate_ca.crt
> ✔ Intermediate private key: /usr/local/etc/step/ca/secrets/intermediate_ca_key
> ✔ SSH user public key: /usr/local/etc/step/ca/certs/ssh_user_ca_key.pub
> ✔ SSH user private key: /usr/local/etc/step/ca/secrets/ssh_user_ca_key
> ✔ SSH host public key: /usr/local/etc/step/ca/certs/ssh_host_ca_key.pub
> ✔ SSH host private key: /usr/local/etc/step/ca/secrets/ssh_host_ca_key
> ✔ Database folder: /usr/local/etc/step/ca/db
> ✔ Templates folder: /usr/local/etc/step/ca/templates
> ✔ Default configuration: /usr/local/etc/step/ca/config/defaults.json
> ✔ Certificate Authority configuration: /usr/local/etc/step/ca/config/ca.json
>
> Your PKI is ready to go. To generate certificates for individual services see > 'step help ca'.
>
> FEEDBACK 😍 🍻
> The step utility is not instrumented for usage statistics. It does not phone
> home. But your feedback is extremely valuable. Any information you can provide
> regarding how you’re using `step` helps. Please send us a sentence or two,
> good or bad at feedback@smallstep.com or join GitHub Discussions
> https://github.com/smallstep/certificates/discussions and our Discord 
> https://u.step.sm/discord.
> Step CA Password file for auto-start not found
> Creating it....
> Please enter the Step CA Password:
> 
> Starting step_ca.
> step_ca is not running.

Issue #1)

> Oct  1 00:38:28 ops step_ca[7822]: error opening /usr/local/etc/step/ca/config/ca.json: open /usr/local/etc/step/ca/config/ca.json: permission denied

This is caused by the permissions to /usr/local/etc/step being wrong

> drwx------  3 root  wheel     4B Oct  1 00:38 step

Fix: chmod go+rx /usr/local/etc/step

Issue #2)

> Oct  1 00:39:17 ops step_ca[7846]: error reading templates/ssh/include.tpl: stat /.step/templates/ssh/include.tpl: no such file or directory

Not sure why it is not using the template directory of /usr/local/etc/step/ca/templates

Fix: ?
Comment 1 Markus Wipp 2021-10-01 08:23:36 UTC
Hi Adam, 

unfortunately I have not been able to reproduce your issue #1. Is there anything else you might have changed from the default installation?

Regarding #2 I fixed the init script in the newest version 0.17.4 of step-certificates and also added --ssh to the init-command. If you want to modify this by hand before it's committed:

@@ -59,8 +59,10 @@ step_ca_startprecmd()
                echo "No configured Step CA found."
                echo "Creating new one...."
                export STEPPATH=${step_ca_steppath}
-               %%PREFIX%%/bin/step ca init
+               %%PREFIX%%/bin/step ca init --ssh
                chown -R ${step_ca_user}:${step_ca_group} ${step_ca_steppath}
+       else
+               export STEPPATH=${step_ca_steppath}
        fi

        if [ ! -e ${step_ca_password} ]; then

If you need further help, please let me know.

Thanks
Markus
Comment 2 Markus Wipp 2021-10-01 08:29:42 UTC
(In reply to Markus Wipp from comment #1)
newest version see Bug 258831
Comment 3 Adam Jimerson 2021-10-04 10:00:07 UTC
(In reply to Markus Wipp from comment #1)

The first issue I reported is odd because it works correctly directly after it was installed. Here's the steps I basically did which triggered it:

1. pkg install step-certificates
2. sysrc step_ca_enable 'YES'
3. service step-ca start
4. (follow the interactive setup process)
5. rm -rf /usr/local/etc/step
6. service step-ca stop
7. vim /usr/local/etc/rc.d/step-ca (add the --ssh arg)
8. service step-ca start
9. (follow the interactive setup process)
10. Notice that /usr/local/etc/step has wrong perms which cases step-ca no fail.

Any attempts to run step 8 and 9 always fails even with reverting /usr/local/etc/rc.d/step-ca to the way it was. The only fix I found was to remove the step-certificates package and it's deps and reinstalling it. Not sure why that fixes it vs just reverting the init script but it did.
Comment 4 Markus Wipp 2021-10-20 18:22:18 UTC
Hi Adam, 

sorry for the long delay due to illness.

I just checked and found the following:

1) the directory /usr/local/etc/step is generated during installation with the correct permissions
2) if the directory is deleted, it will be recreated by the smallstep program with the "wrong" permissions. the fix is as you already found out to recreate the correct permission with "chmod go+rx /usr/local/etc/step"

I think there are possibly three ways to handle this:

1) don't delete the directory, but only its contents
2) file a bug with smallstep-certificates directly, to have it create the directory with the correct permissions
3) add some code in the init-script to check whether the directory exists and create it with the correct permissions if necessary

Best regards
Markus