Certificate authorities
A certificate authority registers a CA in the namespace PKI catalog. Leaf certificates are signed by that CA, or a leaf can set ca.type: self-signed on itself.
Fields are on CertificateAuthority fields.
Router and NATS site CAs created during control plane deploy are a different path. They use fixed names and upload into control plane trust material. See Securing the cluster.
When to use it
spec.type | Use it when |
|---|---|
self-signed | The Controller should generate a new CA key pair. |
direct | CA material is already in a Controller Secret with spec.type: tls. |
k8s-secret | CA material is in a Kubernetes Secret on the control plane cluster. |
For direct, deploy the Secret first. metadata.name on the CA must match that secret name. For self-signed, no secret is required.
There is no update. If the name exists, deploy fails. Delete the CA and create it again.
What deploy does
potctl deploy -f ca.yaml -n my-ecn
Deploy calls create. The API name comes from metadata.name.
apiVersion: datasance.com/v3
kind: CertificateAuthority
metadata:
name: ecn-root-ca
namespace: my-ecn
spec:
subject: "CN=ECN Root CA,O=Example"
type: self-signed
expiration: 3650
Bring-your-own PEM: Secret (type: tls, base64 data), then CertificateAuthority (type: direct), then a leaf Certificate.
How a leaf uses it
A microservice does not name the CA. A leaf kind: Certificate sets ca.type: direct and ca.secretName to this CA name. See Certificates.
CLI
potctl get certificates -n my-ecn
potctl describe certificate ecn-root-ca -n my-ecn
potctl delete certificate ecn-root-ca -n my-ecn
There is no separate certificate-authority subcommand. describe certificate prints the CA as kind: CertificateAuthority, including the private key. delete certificate detects a CA and prompts before delete. There is no attach.
Console
Config → Certificates lists CAs and leaf certificates. See Configuration.