TLS Peer Verification Behavior Clarification for mTLS in Warm Standby and Schema Replication on Tanzu RabbitMQ (Erlang 26+)

Products

• VMware Tanzu Data Suite
• VMware Tanzu RabbitMQ

Issue/Introduction

Customers configuring mutual TLS (mTLS) for Warm Standby Replication (WSR) or Schema Replication on Tanzu RabbitMQ with Erlang 26+ often see TLS handshake-related messages in the logs concerning peer verification.

Even when valid client certificates are provided, internal logs may show warnings or errors related to peer certificate verification. This creates confusion because it appears to contradict documentation that recommends (or requires) setting verify = verify_none for the replication client configuration.

In reality, replication links continue to function normally — nothing is broken — but customers seek clarification on the correct (and expected) configuration approach.

Environment

• Platform: Tanzu RabbitMQ (All deployments)
• Runtime: Erlang 26+
• Plugins: rabbitmq_schema_definition_sync, rabbitmq_standby_replication

Cause

The Schema Replication and Warm Standby Replication plugins act as internal TLS clients when connecting from the downstream/standby node to the upstream/primary node.

With the hardened TLS stack in Erlang 26+, the default client behavior changed to verify_peer. The plugin background sync workers have a known limitation in how they handle server certificate chain validation in this context, which can produce verification warnings (or in some cases prevent clean handshakes) even with correctly supplied certificates.

Resolution

The recommended configuration uses asymmetric verification handling:

• On the downstream/standby node (client role): Bypass server certificate validation by setting verify = verify_none while still supplying the client certificate. This is required for reliable operation under Erlang 26+.
• On the upstream/primary node (server role): Continue to enforce full client certificate verification using your standard mTLS listener configuration (verify_peer + fail_if_no_peer_cert = true).

Example advanced.config (Downstream / Standby Node)

[
  {rabbit, [
    %% Core broker configurations (if any)
  ]},

  %% Schema Definition Sync
  {schema_definition_sync, [
    {ssl_options, [
      {cacertfile, "/path/to/ca_certificate.pem"},
      {certfile,   "/path/to/client_certificate.pem"},
      {keyfile,    "/path/to/client_key.pem"},
      {verify,     verify_none}   %% Required for Erlang 26+ compatibility
    ]}
  ]},

  %% Warm Standby Replication
  {standby, [
    {replication, [
      {downstream, [
        {ssl_options, [
          {cacertfile, "/path/to/ca_certificate.pem"},
          {certfile,   "/path/to/client_certificate.pem"},
          {keyfile,    "/path/to/client_key.pem"},
          {verify,     verify_none}   %% Required for Erlang 26+ compatibility
        ]}
      ]}
    ]}
  ]}
].

 

Verification

After applying the configuration and restarting the affected node(s):

1. Confirm the downstream node establishes replication connections without fatal TLS handshake failures.
2. Check upstream logs to verify that incoming replication connections are correctly authenticating via the presented client certificate.
3. Validate that schema sync / warm standby replication is functioning as expected (e.g. via rabbitmqctl status, replication metrics, or queue/schema consistency checks).

Additional Information

References

• RabbitMQ TLS / SSL Configuration Documentation (covers ssl_options.verify and peer verification)
• RabbitMQ Erlang Version Requirements & Compatibility (details on Erlang 26+ TLS client default changes)
• Tanzu RabbitMQ Warm Standby Replication (Standalone/RPM) (includes TLS configuration examples for schema sync and standby replication)
• Tanzu RabbitMQ Warm Standby Replication for Kubernetes (TLS setup guidance)
• Broadcom Knowledge Article: RabbitMQ 3.13 + Erlang 26 TLS Verification Changes

Additional Notes

• This client-side verify_none setting is expected behavior with the current plugin implementation on Erlang 26+ and does not compromise the overall mTLS security model when the network link between sites is trusted.
• Ensure certificate files are readable by the RabbitMQ process user.
• For production deployments, consider network-level protections (VPN, private connectivity) between primary and standby sites.