Support routing based on TLS client certificate presence/signer for mixed-auth endpoints on shared port

[akrambek]

Summary

When multiple products/endpoints share the same port with different authentication mechanisms (e.g., mTLS with one CA, mTLS with a different CA, or API keys with no client cert), the current TLS server configuration cannot handle them correctly.

Problem

The tls binding's mutual option is a connection-level decision made before any routing occurs. If all products on a port use mTLS with the same CA, mutual: required works fine. But if there is a mix — some products using mTLS (possibly with different CAs) and others using API keys — then:

1. mutual: required cannot be used because API key clients have no client certificate.
2. mutual: requested would need to be used instead, making the cert optional.
3. After TLS handshake, routing would need to branch based on:
   • Whether a client certificate was presented at all.
   • Which CA signed the client certificate (to distinguish between different mTLS products).

Neither of these routing conditions is currently supported.

Impact

The zilla-plus gateway schema for multi-product configurations on a shared port currently assumes all endpoints on that port use the same auth mechanism. Mixed mTLS/API-key auth on a shared port is a gap that cannot be bridged without this capability.

Proposed Solution

Add support for routing guards/rules based on:

• Presence of a TLS client certificate (tls.client.cert present/absent)
• The issuer/signer of the TLS client certificate

This would allow mutual: requested at the TLS layer and then policy-driven routing per product based on cert attributes.