Loading
fix(dev-ca): add additional_hostnames to wildcard certificate SANs
What does this merge request do and why?
This MR makes the built-in dev-CA cover a cluster's additional hostnames, not just its primary one.
The builtin:dev-ca component issues a wildcard TLS certificate for local development. It only covered cluster.network.hostname (<hostname> and *.<hostname>). Hostnames listed under cluster.network.additional_hostnames were added to /etc/hosts but never reached the certificate, so a sibling host such as registry.caproni.test failed TLS verification with a name mismatch.
Two changes close the gap:
- Each additional hostname is appended as an exact SAN to the dev-CA Certificate at deploy time. The primary hostname and its wildcard keep using the existing configMapGenerator replacements; the variable-length list of additional hostnames, which the fixed-index replacement scheme cannot express, is written structurally into the Certificate's
dnsNames(parsed and re-marshalled, never string-templated), skipping empty and duplicate entries. - The dev CA's X.509 Name Constraints are extended to permit those same additional hostnames, so the CA is authorized to sign for every SAN the certificate now carries. A boundary-aware check keeps an unrelated name that merely shares a suffix out of the permitted set.
References
Closes #300
How to set up and validate locally
- In a
caproni.yaml, add one or more entries undercluster.network.additional_hostnamesalongsidehostname. - Run
caproni up(or buildbuiltin:dev-ca). The generatedcaproni-wildcardCertificate'sspec.dnsNamesnow lists the primary hostname, its wildcard, and every additional hostname. - Confirm a sibling host served by the dev-CA certificate no longer reports a TLS name mismatch.
Edited by Jeston Singh