Trusting the dev CA
Browsers and tools reject the certificates your local cluster serves unless they trust the authority that signed them. Xianyun generates a certificate authority (CA) for the project and can install it in your trust stores.
$ xianyun ca inspect # show the CA, creating it on first use
$ xianyun ca trust # install it (asks for sudo)
$ xianyun ca untrust # remove it
Over MCP, ca trust and ca untrust are gated. ca inspect isn’t, and it creates the CA’s key pair the first time it runs.
What gets created
An ECDSA P-256 key pair, valid for ten years, stored per profile under ~/.local/share/xianyun/<profile>/pki/. The files ca.key and ca.crt live in a gen-* directory, and a current symlink points at the live one. Xianyun swaps the symlink atomically, so a reader never sees half a CA.
When the hostnames or cluster domain in your config change, Xianyun re-signs the CA with the same key. If the CA has expired it makes a new one.
$ xianyun ca inspect
Caproni Dev CA
Path: ~/.local/share/xianyun/xianyun/pki/current/ca.crt
Subject: Caproni Dev CA
...
Constraints: [.local .test .svc]
The dates print as raw SystemTime values today. That’s a known display bug.
What it’s allowed to sign
The CA has Name Constraints, so a client that honours them will only accept certificates from this CA for the permitted names. The permitted names are always .local, .test, and .svc, plus your configured hostname and cluster domain when they fall outside those. A hostname like gitlab.dev gets added as its own entry.
The defaults cover every name under those three domains, not only your project’s, and whether a given client enforces Name Constraints varies and hasn’t been tested here. Don’t treat the constraint as a guarantee.
Where it’s installed
| Platform | Location |
|---|---|
| Linux | The system anchor directory, then update-ca-certificates or update-ca-trust |
| macOS | The System keychain |
| Firefox and other NSS databases | Through certutil, if it’s installed. A failure here is reported as a note and doesn’t fail the command. |
untrust also removes the entries older Caproni versions installed.
Where the key goes
A Kustomize deployer using builtin:dev-ca puts the CA’s certificate and key into the cluster as a Secret so cert-manager can issue certificates from it. Anyone who can read Secrets in the cluster can read the key. For a local development cluster that’s usually acceptable, and the Name Constraints are what limit the damage. That path can’t run today, because deployers can’t run yet. See Known limitations and TM-PKI-002.