3.9 KiB
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:
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.