Fix to this error: Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown?

Environment:

• Product: Tableau Server 2026.2 (20262.26.0912.1023)
• Operating System: Windows Server
• Deployment: 4-node Tableau Server cluster
• Nodes 2 and 3 are configured to run Backgrounder services. Before the upgrade, each node had one Backgrounder instance. Following the upgrade, we added one additional Backgrounder instance to each node, bringing the total to two Backgrounder instances per node.

Issue Description:

The issue started immediately after upgrading Tableau Server to version 2026.2 and adding a fifth server (node5) configured as a Tableau Server Independent Gateway (TSIG) load balancer.

Node5 was subsequently removed and no longer appears in tsm topology list-nodes. However, the errors continue.

As part of the changes, we also increased the number of Backgrounder instances on nodes 2 and 3 from one to two per node. Both Backgrounder instances on each node are running normally.

The ZooKeeper client running inside the Non-Interactive Microservice Container on nodes 2 and 3 repeatedly fails TLS hostname verification when connecting to all three Coordination Service nodes.

The following error appears continuously:

java.security.cert.CertificateException: No name matching tableau-c0X found

On the Coordination Service side, the failures appear as SSLHandshakeException: certificate_unknown, occurring approximately 600 times per minute per ensemble node.

Investigation and Troubleshooting Performed:

1. Executed tsm security rotate-coordination-service-secrets on October 2, 2026, at 20:01 UTC. The newly generated ensemble certificate is self-signed, has CN=*, and does not contain Subject Alternative Names (SANs).
2. Confirmed that the ZooKeeper server process (appzookeeper) runs with -Dzookeeper.ssl.hostnameVerification=false.
3. Compared the ZooKeeper client configurations used by Backgrounder and Non-Interactive services on the same node. Both have equivalent TSM-generated configurations, but Backgrounder connects successfully while Non-Interactive continues reporting hostname verification errors.
4. Executed tsm security regenerate-internal-tokens. The command completed, but the issue persists.
5. Confirmed that there are no pending TSM changes and that NTP synchronization is working correctly.
6. No PKIX certificate chain validation errors have been observed.
7. No manual modifications have been made to Tableau-generated keystores, certificates, or configuration files.

Current System Status:

All Tableau Server services are operational.

Running tsm status -v shows that all services are in the Running state. Dashboards, extracts, background jobs, and other Tableau functionality appear to be working normally.

Both Backgrounder instances on nodes 2 and 3 are functioning correctly.

However, despite all services running successfully, the TLS errors continue to be generated continuously in the background.

Impact:

The main impact is excessive log generation and disk space consumption:

• noninteractive_node3-0.log has grown to approximately 51 GB as a single log file.
• The appzookeeper services are generating approximately 48 GB of logs per day.
• The continuous errors are creating unnecessary disk I/O and increasing the risk of disk space exhaustion.

Although there is currently no visible functional impact on Tableau Server, the abnormal log growth is a significant operational concern.

Assistance Requested:

We need Tableau Support's assistance to identify and permanently resolve this issue.

Specifically, we would appreciate your guidance on the following:

1. Root cause: Why does the Non-Interactive Microservice Container fail ZooKeeper TLS hostname verification while Backgrounder, using an equivalent TSM-generated configuration, connects successfully?
2. Supported resolution: Is there a supported TSM configuration key, documented workaround, hotfix, or patch for Tableau Server 2026.2 that resolves this behavior?

The log looks like:  

2026-10-08 22:10:28.037 +0000 13552 nioEventLoopGroup-4-29 : ERROR org.apache.zookeeper.server.NettyServerCnxnFactory - Unsuccessful handshake with session 0x0 

2026-10-08 22:10:28.038 +0000 13552 nioEventLoopGroup-4-29 : WARN  org.apache.zookeeper.server.NettyServerCnxnFactory - Exception caught 

io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown 

at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:515) 

at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296) 

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) 

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) 

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) 

at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) 

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) 

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) 

at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) 

at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:171) 

at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:796) 

at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732) 

at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658) 

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) 

at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:1007) 

at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) 

at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) 

at java.base/java.lang.Thread.run(Thread.java:840) 

Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown 

at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) 

at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) 

at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:370) 

at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293) 

at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:209) 

at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172) 

at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) 

at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) 

at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) 

at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) 

at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679) 

at io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:308) 

at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1486) 

at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1377) 

at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1428) 

at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:545) 

at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:484) 

... 17 more