Support for .security TLD and Certificate Validation in NATS v2.11.1

[dohdat]

Hi team,

We’re seeing an issue with NATS client connectivity due to certificate validation failures. The error is related to mismatches in the Subject Alternative Names (SANs), specifically for domains ending in .security. Example error:

Certificate doesn't match any of the subject alternative names: [server01.domain.security, server01, server02.domain.security, server02, *.domain.security]

Despite server02.domain.security being listed, the client reports a mismatch.

A few questions:

Does NATS v2.11.1 have known fixes or changes related to certificate SAN validation?

Is there a way to configure the NATS client (e.g., nats-js.conf) to skip or relax certificate validation for testing purposes?

Are there known issues or special considerations when using .security TLDs with NATS?

Any guidance would be appreciated.

Thanks!

[philpennock]

There is nothing special about .security in our code, as far as I know.
Also, what sort of connection is this? You mention the nats-server version, but don't mention what is connecting. Is this a server<-> server connection, such as in Routes or Gateways? Or is this a client failing to validate, and if so which language/library is used by the client?

Assuming that this is the nats-server acting as the TLS client, then:

1. beware that there are multiple TLS blocks which can appear, for the different roles the server is fulfilling, and you'll need to make sure that you're configuring the correct block for this scenario; they don't inherit;
2. in the relevant set of TLS options for the scenario needed, you can set the insecure boolean to true, which will skip certificate verification.

I would check carefully to make sure that the name the TLS client is using to connect is the name of the server you expect, and isn't (for example) an IP address.

The NATS client libraries have special handling for IP addresses: if they originally connect with a hostname, but learn new connection addresses from the server for reconnect, then when connecting to reconnect and it is an IP address, then it will validate the original hostname instead.

Otherwise, I don't think there's special handling for IP addresses.