60 lines
2.3 KiB
Markdown
60 lines
2.3 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 R3* private key is managed externally from Step CA. It is
|
|
stored offline (on a flash drive in a fireproof safe). 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 R3* replaces *DCH Root CA R2*, which never ended up being used,
|
|
and *DCH Root CA R1*, which has not been used for some time.
|
|
|
|
|
|
## Online Intermediate CA
|
|
|
|
Step CA manages the *DCH CA R3* 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.
|
|
|
|
|
|
### ACME Provisioner
|
|
|
|
Hosts can obtain certificates signed by *DCH CA R3* using the ACME protocol.
|
|
The CA will only sign certificates for names that map to addresses controlled
|
|
by the requesting client. For most machines, that means they can only get a
|
|
certificate for their hostname. Other names can be added using DNS CNAME
|
|
records.
|
|
|
|
Only the `http-01` and `tls-alpn-01` challenges will work, since clients cannot
|
|
modify DNS server records.
|
|
|
|
|
|
### OIDC Provisioner
|
|
|
|
Step CA is configured to integrate with Authelia for OpenID Connect
|
|
authorization. Users can obtain personal certificates using this provisioner.
|
|
|
|
|
|
## 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
|