Allow ACME-issued certificates for public endpoint routes#1938
Allow ACME-issued certificates for public endpoint routes#1938marbindrakon wants to merge 1 commit into
Conversation
When a user supplies a custom TLS secret for a public endpoint route (via apiOverride), the operator required tls.crt, tls.key AND ca.crt. Certificates issued by an ACME issuer (e.g. Let's Encrypt) do not populate ca.crt: the issuing chain is delivered in tls.crt and the root is publicly trusted, so ca.crt is not needed. Make ca.crt optional on this path: - Extract the secret key check into validateRouteCertSecret, which now only requires tls.crt and tls.key. - Only set the route's CACertificate when the secret actually provides ca.crt, instead of writing an empty value. This lets ACME-issued certificates be consumed for public endpoints without a synthetic ca.crt entry. Intermediates continue to be served because cert-manager packs the full chain into tls.crt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Andrew Austin Byrum <aaustin@redhat.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: marbindrakon The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @marbindrakon. Thanks for your PR. I'm waiting for a openstack-k8s-operators member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
OpenStackControlPlane CRD Size Report
Threshold reference
|
|
As proposed, this patch will not stop a user from providing a privately-signed certificate secret. In that case, they would be responsible for adding the correct root to the CA bundle using the existing mechanism. |
1 participant
When a user supplies a custom TLS secret for a public endpoint route
(via
apiOverride), the operator required the secret to containtls.crt,tls.keyandca.crt. Certificates issued by an ACMEissuer (e.g. Let's Encrypt) do not populate
ca.crt: the issuing chainis delivered inline in
tls.crt, and the signing root is publiclytrusted, so a separate
ca.crtentry is neither produced nor needed.This made it impossible to use ACME-issued certificates for public
endpoints without synthesising a
ca.crtkey.This makes
ca.crtoptional on that path:validateRouteCertSecret,which now requires only
tls.crtandtls.key.CACertificateis set only when the secret actuallyprovides
ca.crt, instead of writing an empty value.Certificate chains continue to be served correctly because cert-manager
packs the full issuing chain into
tls.crt;CACertificateis onlyused to advertise an additional custom CA, which remains supported when
present. Re-encrypt (TLSE) routes are unaffected — their
DestinationCACertificateis still sourced from the internal CA bundle.This covers the "bring your own secret" flow. Having the operator
manage an ACME
Certificatedirectly (which additionally requiresguarding the custom-issuer CA-extraction path and splitting public vs
internal SAN profiles) is intentionally out of scope here.
Jira: RHOSRFE-109
🤖 Generated with Claude Code