Pass in enabled mTLS spec when a cert is provided

[david049]

What was changed

Enable mtls auth when a cert is passed in

Why?

Checklist

1. Closes

2. How was this tested:

3. Any docs updates needed?

---

Note

Medium Risk
Changes namespace auth spec sent to Temporal Cloud; incorrect defaults could leave mTLS disabled or enable it unexpectedly, but the change aligns behavior with supplying cert material.

Overview
mTLS is now explicitly turned on whenever the CLI or internal namespace client sends CA certificates or certificate filters, by setting MtlsAuthSpec.Enabled: true on create and on namespace updates that initialize or extend MtlsAuth.

CreateNamespace sets Enabled when --ca-certificate is provided and when certificate filters are set (including filters-only). The internal AddCACerts, DeleteCACerts (when a bundle remains), and cert-filter add/remove paths use the same default when they create a new MtlsAuth block.

Unit expectations and the namespace create integration test were updated to assert Enabled, accepted CA material, and filters; create e2e now provisions a test CA via --ca-certificate instead of relying only on API key auth for that scenario.

^{Reviewed by Cursor Bugbot for commit 72e041b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Enabled unset on existing MtlsAuth

High Severity

In AddCACerts, MtlsAuth.Enabled is set to true only when spec.MtlsAuth is nil. When the namespace already has an MtlsAuth block (the usual add-cert path), only AcceptedClientCa is updated, so Enabled stays false and mTLS can remain off despite CA changes.

 

^{Reviewed by Cursor Bugbot for commit adf5848. Configure here.}

[cursor]

Existing mTLS stays disabled

High Severity

AddCACerts and AddCertFilters only set MtlsAuth Enabled when the spec pointer was nil. If the namespace already has a non-nil MtlsAuth with Enabled false (e.g. after older create paths that supplied CAs without enabling), adding CAs or filters updates those fields but leaves mTLS disabled, so the PR’s intent is not applied on update.

Additional Locations (1)

• internal/namespace/cert_filter.go#L43-L54

 

^{Reviewed by Cursor Bugbot for commit 93abd77. Configure here.}

[david049]

Is there ever a case where we add certs/filters and we don't have it enabled?

[cursor]

Delete filters enables empty mTLS

Low Severity

In DeleteCertFilters, when MtlsAuth was nil the code now creates MtlsAuthSpec{Enabled: true} and pushes an update with empty CertificateFilters. A delete on a namespace with no mTLS config can turn mTLS on without CA material, which this change introduces via Enabled: true on that init path.

 

^{Reviewed by Cursor Bugbot for commit 93abd77. Configure here.}

[david049]

Is there ever a case where we have cert filters enabled, we delete it, and the namespace has enabled:false on mtls?

[cursor]

mTLS not enabled on add

Medium Severity

This PR turns on MtlsAuth.Enabled when creating a namespace with certs or filters, but AddCertFilters and AddCACerts only set Enabled: true when MtlsAuth was nil. If the namespace already has an MtlsAuth block with Enabled: false, adding filters or CAs updates the spec without enabling mTLS.

Additional Locations (1)

• internal/namespace/cert.go#L55-L61

 

^{Reviewed by Cursor Bugbot for commit 9612dd7. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 5 total unresolved issues (including 4 from previous reviews).

^{Reviewed by Cursor Bugbot for commit a1a1098. Configure here.}

[cursor]

mTLS stays disabled adding certs

Medium Severity

In DeleteCertFilters, when spec.MtlsAuth is nil the code creates MtlsAuth with Enabled: true before assigning the filter list. With no existing filters that yields an update that turns mTLS on with no CAs and no filters.

Additional Locations (1)

• internal/namespace/cert_filter.go#L43-L54

 

^{Reviewed by Cursor Bugbot for commit a1a1098. Configure here.}