certz: clarify that Rotate RPCs not be interrupted by TLS->mTLS transitions

[brianneville]

If a server is moved from TLS -> mTLS (i.e. by rotation of a trust_bundle to a particular SSL profile which did not previously have a trust_bundle assigned), then the server may require a reload to apply these changes.
Such a reload would interrupt the Certz Rotate RPC if it was ongoing via that server.
Clarify here that servers should explicitly not allow this to occur.

[ssachinbharadwaj]

I’m not sure this should be enforced at the proto level. This behaviour seems tied to how a specific implementation handles TLS → mTLS transitions, rather than a fundamental API constraint.
Encoding this as a required InvalidArgument would both make the API less implementation-agnostic and introduce additional operational friction (e.g., requiring operators to switch profiles after rotation).

[marcushines]

I’m not sure this should be enforced at the proto level. This behaviour seems tied to how a specific implementation handles TLS → mTLS transitions, rather than a fundamental API constraint. Encoding this as a required InvalidArgument would both make the API less implementation-agnostic and introduce additional operational friction (e.g., requiring operators to switch profiles after rotation).

so can you explain how this would be accomplished exactly given the current technologies available?

[ssachinbharadwaj]

so can you explain how this would be accomplished exactly given the current technologies available?

Sure.

Before diving into gRPC internals, I should note that I don’t have full visibility into the specific implementation details (e.g., language, runtime, or gRPC version) used by other vendors, so their observed behaviour may be influenced by those factors.

In the gRPC core stack, server credentials can either be provided at startup or dynamically via grpc_ssl_server_credentials_create_options_using_config_fetcher(), where the application receives callbacks to update certificates/CA as needed.
Looking into the gRPC core internals, this limitation appears to be specific to gRPC. In particular, there is currently no mechanism to update the client_certificate_request field from the config within try_replace_server_handshaker_factory().
Ref: https://github.com/grpc/grpc/blob/eb0a9adf1f316ed2d5d19864e4c103975adc3664/src/core/credentials/transport/ssl/ssl_security_connector.cc#L378
Other fields (like pem_key_cert_pairs) are refreshed from the config, which is populated by the application. With some extension to the config structure, it should be possible for the application to set the desired client_certificate_request value and apply it to new connections without impacting existing ones.

For comparison, systems like NGINX handle TLS → mTLS transitions via config updates followed by a graceful reload (nginx -s reload), which does not drop existing connections.

More broadly, neither OpenSSL nor the TLS protocol itself mandates that such a transition must terminate existing connections. That said, if there are any references or specifications that suggest otherwise, I’d really appreciate it if you could share them. I’d be happy to take a closer look.

We’ve also verified in our implementation that TLS → mTLS transition works gracefully via certz.Rotate, so this behaviour does not appear to be generally applicable.