apache/seatunnel · warning

TLS hostname verification disabled - not recommended for pro

Error message

TLS hostname verification disabled - not recommended for production

What it means

AbstractAuthenticationProvider.configureTLS sets a NoopHostnameVerifier when tls_verify_hostnames=false, meaning the certificate's hostname is not checked against the connection host. A warn is logged because this enables man-in-the-middle attacks; nothing fails.

Source

Thrown at seatunnel-connectors-v2/connector-elasticsearch/src/main/java/org/apache/seatunnel/connectors/seatunnel/elasticsearch/client/auth/AbstractAuthenticationProvider.java:110

                                keystorePath, keystorePassword, truststorePath, truststorePassword);

                if (sslContext.isPresent()) {
                    httpClientBuilder.setSSLContext(sslContext.get());
                    log.debug("Custom SSL context configured with keystore/truststore");
                } else {
                    log.debug("No custom SSL context configured, using default");
                }
            } else {
                // Trust all certificates (not recommended for production)
                SSLContext sslContext =
                        SSLContexts.custom().loadTrustMaterial(new TrustAllStrategy()).build();
                httpClientBuilder.setSSLContext(sslContext);
                log.warn("TLS certificate verification disabled - not recommended for production");
            }

            if (!tlsVerifyHostnames) {
                httpClientBuilder.setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE);
                log.warn("TLS hostname verification disabled - not recommended for production");
            }

            log.debug(
                    "TLS configuration completed - certificate verification: {}, hostname verification: {}",
                    tlsVerifyCertificate,
                    tlsVerifyHostnames);
        } catch (Exception e) {
            throw new RuntimeException("Failed to configure TLS settings", e);
        }
    }
}

View on GitHub (pinned to cf67b549a7)

Solutions

1. Set tls_verify_hostnames=true
2. Use the hostname that matches the certificate's SAN/CN in the URL
3. Reissue or regenerate the certificate with the correct SAN entries

Example fix

// before
url = "https://10.0.0.5:9200"
tls_verify_hostnames = false
// after
url = "https://es.internal.example.com:9200"
tls_verify_hostnames = true

// ensure hostname in URL matches certificate SAN
openssl x509 -in es.crt -noout -text | grep -A1 'Subject Alternative Name'

When it happens

Trigger: HTTPS Elasticsearch connection configured with tls_verify_hostnames=false, e.g. when the cert CN doesn't match the hostname used in the URL.

Common situations: Connecting via IP address or internal DNS alias while the certificate was issued for a different name; copy-pasted security-disabled configs from dev.

Understand the failure class

• SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

• Failed to load AmazonDocumentDB TLS CA bundle:
• TLS certificate verification disabled - not recommended for
• AmazonDocumentDB option 'tls_ca_file' is required when TLS i
• AmazonDocumentDB TLS CA bundle is not a readable file:
• AmazonDocumentDB TLS CA bundle contains no certificates:

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/a5473fb23f37a228. Report an issue: GitHub.