Dustin C. Hatch
3ba83373f3
Although most libraries support ED25519 signatures for X.509 certificates, Firefox does not. This means that any certificate signed by DCH CA R3 cannot be verified by the browser and thus will always present a certificate error. I want to migrate internal services that do not need certificates that are trusted by default (i.e. they are only accessed programatically or only I use them in the browser) back to using an internal CA instead of the public *pyrocufflink.net* wildcard certificate. For applications like Frigate and UniFi Network, these need to be signed by a CA that the browser will trust, so the ED25519 certificate is inappropriate. Thus, I've decided to migrate back to DCH CA R2, which uses an EdDSA signature, and can therefore be trusted by Firefox, etc.
61 lines
2.4 KiB
Markdown
61 lines
2.4 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 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 R2* replaces *DCH Root CA R1*, which has not been used for some
|
|
time. *DCH Root CA R3* also exists, but it is based on an ED25519 signature,
|
|
which is not supported by Firefox.
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
### ACME Provisioner
|
|
|
|
Hosts can obtain certificates signed by *DCH CA R2* 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
|