"Transport client authentication no longer supported" error due to mismatch in the order of nodes_dn

Security
1

When attempting to join nodes / authenticate TLS clients, OpenSearch throws:

Caused by: org.opensearch.OpenSearchException: Transport client authentication no longer supported.
at org.opensearch.security.ssl.util.ExceptionUtils.createTransportClientNoLongerSupportedException(ExceptionUtils.java:80) ~[?:?]

During debugging we discovered the DN values used in nodes_dn and plugins.security.authcz.admin_dn were textually the same, but the order of components in the Distinguished Name (DN) differed (e.g. CN=… , O=… , C=… vs C=… , O=… , CN=…). OpenSearch appears to validate DNs using RFC1779 format and fails authentication when the DN component order does not match the expected pattern even when the values themselves are identical.

Relevant documentation:
https://docs.opensearch.org/latest/troubleshoot/tls/#check-for-special-characters-and-white-space-in-dns
https://www.ietf.org/rfc/rfc1779.txt

Steps to reproduce:

  1. Generate certificate(s) for node/client with subject DN as CN=, O=, C= (order A).
  2. Configure plugins.security.nodes_dn using the same attribute values but in order B (e.g. C=, O=, CN=).
  3. Perform the same with plugins.security.authcz.admin_dn
  4. Restart node / attempt to join cluster.
  5. Observe the exception above and refused authentication.

Questions / requests

  1. Is the strict string-order validation of DNs intentional and required for security? If so, could the docs be updated to explicitly call this out with examples and recommended formatting?

  2. Would it be possible to make the DN comparison canonical (i.e., normalize/parse and compare attributes regardless of order) to reduce operator confusion while preserving security?

  3. If canonical comparison is not acceptable, can the exception and log message be improved to indicate a DN ordering mismatch so the root cause is clearer?

  4. Are there recommended best practices or tooling to ensure consistent DN ordering during certificate generation?

Thanks in advance.

2

@Ramya5817 Did you have a look at this OpenSearch documentation?

Also, with nodes_dn you can use regular expression as described in OpenSearch Documentation.

3

Hi @pablo

Yes, we tried using a regular expression in nodes_dn and it worked.
Example:
nodes_dn:

  • ‘CN=*’

However, providing only ‘*’ does not work when our goal is to bypass DN validation entirely:

Example:
nodes_dn:

  • ‘*’
    The wildcard/regex only succeeds when the DN format (for example, starting with CN=) is known. For certificates where the DN starts with a different attribute (e.g. C=…), CN=* will not match.

Additionally, regex/wildcards are not permitted for authcz.admin_dn.
Is there any way to bypass these validations for authcz.admin_dn or is it restricted to exact DNs only?

4

@Ramya5817 Have you considered using OID instead?