101 lines
3.9 KiB
Markdown
101 lines
3.9 KiB
Markdown
# Step CA
|
|
|
|
[Step CA] is an open-source online X.509 and SSH certificate authority servier.
|
|
It provides an HTTP API for remote control via the `step` command, which is
|
|
used by clients for certificate issuance and administrators for configuration
|
|
and control. It also supports other certificate issuance protocols, including
|
|
[ACME]. Clients can authenticate using a variety of protocols, such as JWK,
|
|
OpenID Connect, mTLS, and more.
|
|
|
|
|
|
## Offline Root CA
|
|
|
|
The *dch Root CA R2* private key is managed externally from Step CA. It is
|
|
stored offline (on a flash drive in a fireproof save). Only the CA certificate
|
|
is used by the online CA service, where it is provided to clients to include in
|
|
as a trust anchor in their respective certificate stores.
|
|
|
|
*dch Root CA R2* replaces *dch Root CA R1*, which has not been used for some
|
|
time.
|
|
|
|
|
|
## Online Intermediate CA
|
|
|
|
Step CA manages the *dch CA R2* intermediate certificate authority. The
|
|
private key for this CA is stored in the `intermediate_ca.key` file, encrypted
|
|
with the password in `password`. This key pair is needed by the online CA to
|
|
sign end-entity certificates.
|
|
|
|
|
|
## SSH CA
|
|
|
|
In addition to X.509 (TLS) certificates, Step CA can also manage SSH
|
|
certificates. These can be used in place of "plain" SSH keys that must be
|
|
managed out-of-band (i.e. `~/.ssh/known_hosts` and `~/.ssh/authorized_keys`).
|
|
|
|
Instead of maintaining a database of hosts' public keys, clients can trust the
|
|
CA certificate that signs the hosts' certificates. To do so, simply add a
|
|
single line to `~/.ssh/known_hosts`:
|
|
|
|
```
|
|
@cert-authority *.pyrocufflink.blue ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJ8KfNjDh0R/jCmPcJrVafvmuw5JZw+cKoy9RCYNwHsRwPoRHfyzjV1VUZolJfEz+Qm3u+mgYJ/oSquCelY84xE=
|
|
```
|
|
|
|
Any host with a hostname that matches `*.pyrocufflink.blue` and presents a
|
|
certificate signed by the listed certificate will be automatically trusted; the
|
|
`ssh` client will not prompt for manual key verification on the first
|
|
connection.
|
|
|
|
Similarly, hosts can trust client keys that are signed by the CA by *either*
|
|
adding the certificate to per-user `~/.ssh/authorized_keys` files *or* by
|
|
setting the global `TrustedUserCAKeys` parameter in the SSH server
|
|
configuration.
|
|
|
|
`~/.ssh/authorized_keys`:
|
|
```
|
|
cert-authority ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBImIoTTmhynCVy/vJ/Q2bWydzqVsvwhGvDgBbklw0eDt8UEbbP9HHPhxiMDtiAhbvRTg5BhYVAlR1MgdooT5dwQ=
|
|
```
|
|
|
|
`/etc/ssh/sshd_config`:
|
|
```
|
|
TrustedUserCAKeys /etc/ssh/ca.pub
|
|
```
|
|
|
|
`/etc/ssh/ca.pub`:
|
|
```
|
|
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBImIoTTmhynCVy/vJ/Q2bWydzqVsvwhGvDgBbklw0eDt8UEbbP9HHPhxiMDtiAhbvRTg5BhYVAlR1MgdooT5dwQ=
|
|
```
|
|
|
|
SSH host certificates are typically valid for 30 days, so hosts need to have
|
|
some automation in place to automatically renew their certificates. Using the
|
|
"SSHPOP" provisioner, hosts can use the `step ssh renew` command to renew their
|
|
certificates; existing signed SSH certificates are usable as authentication
|
|
credentials.
|
|
|
|
SSH user certificates are typically valid for 24 hours. Clients will need to
|
|
request a new certificate every day using the `step ssh login` command:
|
|
|
|
```sh
|
|
step ssh login --provisioner=authelia dustin
|
|
```
|
|
|
|
Note the `--provisioner=authelia` argument seems to be required, even if a
|
|
default provisioner is specified in `~/.step/config/defaults.json`.
|
|
|
|
The final positional argument is the name of the *remote* SSH user, *not* the
|
|
user logging in to the OIDC IdP.
|
|
|
|
|
|
## NodePort Service (No Ingress)
|
|
|
|
Step CA supports authenticating clients using mTLS, such as to renew a user
|
|
certificate. For this to work, the client must communicate directly with the
|
|
server; proxies and load balancers must not intercept the communication or
|
|
provide TLS termination, as then the server would not have access to the client
|
|
certificate. As such, the service is exposed as a NodePort and not via an
|
|
Ingress.
|
|
|
|
|
|
[Step CA]: https://smallstep.com/docs/step-ca/
|
|
[ACME]: https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment
|