Removing custom hostname from HTTPProxy leaves orphaned certificate resource, blocking TrafficProtectionPolicy acceptance

[kevwilliams]

Summary

When a custom hostname is added to an HTTPProxy, a certificate resource is created for it (e.g. proxy-www-kev1n-org-https-hostname-0). If the custom hostname is later removed, the certificate resource is not cleaned up. This leaves the proxy stuck with a pending cert, which blocks TrafficProtectionPolicy from reaching Accepted: True.

Steps to Reproduce

1. Create an HTTPProxy with a custom hostname (e.g. www.kev1n.org)
2. Attach a TrafficProtectionPolicy to the gateway
3. Remove the custom hostname from the proxy
4. Observe the policy status remains Accepted: False with message:

   Waiting for TLS certificates to become ready: <proxy-name>-https-hostname-0
   

Expected Behavior

Removing a custom hostname from an HTTPProxy should garbage-collect the associated certificate resource. The policy should re-evaluate and reach Accepted: True once the hostname (and its cert dependency) is gone.

Actual Behavior

The orphaned certificate resource keeps the proxy stuck in a certificate-waiting state indefinitely. The TrafficProtectionPolicy never becomes accepted, so WAF rules are never applied even though the proxy is otherwise functional.

Workaround

Create a new proxy without the custom hostname. The policy will be accepted immediately.

[zachsmith1]

After reviewing the code, the certificate-orphaning story may not be the root cause here.

The TPP controller derives which certs to wait on dynamically from the current upstream Gateway spec on every reconcile — it does not hold onto stale cert names. When a hostname is removed from an HTTPProxy, the upstream gateway's listener list is rebuilt without that hostname, so checkHTTPSListenerCertificatesReady simply never adds the corresponding cert to its check set. Meanwhile the gateway reconciler's ensureListenerCertificates compares against the same current-spec desired set and deletes any certs for removed listeners. The TPP also watches Gateway changes, so it would re-reconcile as soon as the gateway is updated.

It's possible you hit a transient race between the HTTPProxy reconcile and the TPP reconcile (the TPP ran one last time while the gateway still had the old listener), but that should self-resolve within seconds.

Could you share a bit more detail to help narrow it down?

• What was the state of the upstream Gateway's spec.listeners after you removed the hostname — did it still have https-hostname-0?
• Did the cert (<proxy-name>-https-hostname-0) still exist in the downstream namespace after removal?
• How long did the TPP stay stuck? Did it eventually recover, or was it truly indefinite?
• Were there any error events on the Gateway or HTTPProxy at the time?

[scotwells]

@zachsmith1 should be able to use the activity service to build a timeline and events for the resources involved.