Separate client TLS configuration for cluster routes/gateways

[ollie123]

Proposed change

Make it possible to specify separate TLS certificates for outbound (client) connections on cluster routes. For example, this might look like:

cluster {
  ...

  # Server certificate, used for inbound connections
  tls {
    cert_file: "path/to/server/cert.pem"
    key_file:  "path/to/server/key.pem"
    verify_and_map: true
  }

  # Separate client certificate, used for outbound TLS to other servers in cluster
  client_tls {
    cert_file: "path/to/client/cert.pem"
    key_file:  "path/to/client/key.pem"
  }

  # Client certificate subject
  authorization {
    user: "O=myorg,CN=client_cn"
  }

  routes = [
    ...
  ]
}

In the above example, if client_tls is set, then the certificate specified within would be used for outbound route connections, with the server/inbound certs specified in the tls block. If client_tls is not set, then the current behaviour is used where tls sets both the server and client cert (for backward compatibility).

I've not used gateways much but I guess this may be useful there too, although I may be wrong.

Use case

Regarding the "Wrong Key Usage" documented here: https://docs.nats.io/running-a-nats-service/configuration/securing_nats/tls#wrong-key-usage

Our internal PKI is incapable of issuing certificates that have both server and client authentication in the extended key usage. Additionally, client certs are issued to service accounts while server certs are issued to hosts; it would be great if we could authorize our service account (which each NATS instance would be running as) as the route user while using the auto-provisioned host certs for the server side of the connection.

Contribution

No response

[wallyqs]

cc @philpennock

[kozlovic]

Note: Gateways and LeafNodes have their own TLS block in the "remotes" definitions, meaning that you can already specify a different "tis{}" block for a given remote connection. So that would be for routes only.