The ticket looked routine: provision a LoadBalancer, a DNS record, and a TLS certificate for a gateway so its HTTPS listener would come up. The suggested approach was described as "hook it up to cert-manager or the tenant wildcard, whichever is standard." Standard, implying this was a well-worn path with an obvious right answer already in place.
It wasn't. There was no standard path to hook into.
What Was Actually There
I went looking for the certificate infrastructure the ticket assumed existed, and found:
- No certificate requests beyond the load balancer's own internal serving cert
- No ACME orders, no challenges
- No wildcard certificate for the tenant
The only certificate issuer anywhere in the cluster was a self-signed ClusterIssuer, used for internal controller and webhook traffic. That's a completely reasonable thing to have — internal, trusted-by-nothing-external traffic doesn't need a real CA chain. What it's not reasonable for is facing real HTTP clients, a meaningful number of which (AI agent frameworks in particular, in this case) will hard-fail the moment they hit an untrusted certificate chain.
The Easy Wrong Answer
The path of least resistance was right there: point the new gateway at the existing self-signed issuer, watch the HTTPS listener come up green, close the ticket. Technically, it would have worked. The listener would have served HTTPS. Nothing in a quick smoke test would have caught the problem.
It also would have quietly shipped a decision nobody actually made on purpose. The ticket implied "give this endpoint real, trusted TLS" — that's what "hook it up to cert-manager, whichever is standard" reads as. Substituting a self-signed cert instead isn't a neutral implementation detail; it's a security posture decision, made by default, by whoever happened to be holding the ticket.
What I Did Instead
I stopped and flagged it as a platform-level gap rather than an implementation task. The honest framing was: this cluster doesn't have real certificate issuance infrastructure yet, and building a gateway on top of a self-signed workaround would bake that gap into a production-facing endpoint, invisibly, until an external client failed loudly on a cert error months later — at a much worse time to discover it than right now, in a ticket about exactly this.
Why This Is Worth Knowing
Tickets get written by people trying to describe an outcome, not necessarily verifying every assumption behind the suggested approach. "Just wire it up to the standard thing" is a completely reasonable way to write a ticket when you believe the standard thing exists. The judgment call isn't about the ticket being wrong to ask — it's recognizing when the quickest way to close it would mean making an architecture decision on someone else's behalf, without them knowing a decision was even being made.
Self-signed issuers are fine, sometimes exactly right, for internal traffic. The moment a client outside your trust boundary is going to see that cert, it stops being an implementation detail and becomes a decision that deserves to be made on purpose.
Takeaways
- "Standard" in a ticket description is a claim, not a fact — worth verifying the infrastructure it assumes actually exists before building on top of it.
- A self-signed cert that "makes HTTPS work" in a smoke test can still be the wrong answer if the audience was ever meant to be external, untrusted clients.
- When the fast path to closing a ticket quietly makes an architecture decision, stop and surface it explicitly — even if it means the ticket doesn't close today.