1
0
Fork 0
kubernetes/step-ca/README.md

2.4 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 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.