Elastic 8.7__enrollement-token__"failed to establish trust with server "

Hi ,

I have a kibana server and an elastic server with differents IP address .

When I want to create a token for kibana with command :

sudo bin/elasticsearch-create-enrollement-token -s kibana

OR

sudo bin/elasticsearch-create-enrollement-token -s kibana --url "https://@ELASTIC IP ADDRESS:9200

I have an error : "Failed to establish trust with server at @ELASTIC IP ADDRESS"

I have a default config with network.host : @ELASTIC IP ADDRESS and http.port: 9200
It's a new install

Any idea ?

Thanks

Any idea ?

my log :

sudo bin/elasticsearch-create-enrollment-token -s kibana

> 14:45:55.875 [main] WARN  org.elasticsearch.common.ssl.DiagnosticTrustManager - failed to establish trust with server at [192.168.200.141]; the server provided a certificate with subject name [CN=elastic], fingerprint [982d15d1bd187a3a62f19ff63cca807045bda55d], no keyUsage and extendedKeyUsage [serverAuth]; the certificate is valid between [2023-04-25T14:36:14Z] and [2025-04-24T14:36:14Z] (current time is [2023-05-02T12:45:55.872722204Z], certificate dates are valid); the session uses cipher suite [TLS_AES_256_GCM_SHA384] and protocol [TLSv1.3]; the certificate has subject alternative names [DNS:localhost,IP:127.0.0.1,IP:192.168.99.162,DNS:elastic]; the certificate is issued by [CN=Elasticsearch security auto-configuration HTTP CA]; the certificate is signed by (subject [CN=Elasticsearch security auto-configuration HTTP CA] fingerprint [0f92f1fc6d9c035d3aca7311b1c7febd113f0d5c] {trusted issuer}) which is self-issued; the [CN=Elasticsearch security auto-configuration HTTP CA] certificate is trusted in this ssl context ([xpack.security.http.ssl (with trust configuration: Composite-Trust{JDK-trusted-certs,StoreTrustConfig{path=/etc/elasticsearch/certs/http.p12, password=<non-empty>, type=PKCS12, algorithm=PKIX}})])
> java.security.cert.CertificateException: No subject alternative names matching IP address 192.168.200.141 found
> 	at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:164) ~[?:?]
> 	at sun.security.util.HostnameChecker.match(HostnameChecker.java:101) ~[?:?]
> 	at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:458) ~[?:?]
> 	at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:432) ~[?:?]
> 	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:238) ~[?:?]
> 	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132) ~[?:?]
> 	at org.elasticsearch.common.ssl.DiagnosticTrustManager.checkServerTrusted(DiagnosticTrustManager.java:80) ~[?:?]
> 	at sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1335) ~[?:?]
> 	at sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1226) ~[?:?]
> 	at sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1169) ~[?:?]
> 	at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396) ~[?:?]
> 	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480) ~[?:?]
> 	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458) ~[?:?]
> 	at sun.security.ssl.TransportContext.dispatch(TransportContext.java:201) ~[?:?]
> 	at sun.security.ssl.SSLTransport.decode(SSLTransport.java:172) ~[?:?]
> 	at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1510) ~[?:?]
> 	at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1425) ~[?:?]
> 	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455) ~[?:?]
> 	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426) ~[?:?]
> 	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:578) ~[?:?]
> 	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:187) ~[?:?]
> 	at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:142) ~[?:?]
> 	at org.elasticsearch.xpack.core.common.socket.SocketAccess.lambda$doPrivileged$0(SocketAccess.java:42) ~[?:?]
> 	at java.security.AccessController.doPrivileged(AccessController.java:569) ~[?:?]
> 	at org.elasticsearch.xpack.core.common.socket.SocketAccess.doPrivileged(SocketAccess.java:41) ~[?:?]
> 	at org.elasticsearch.xpack.core.security.CommandLineHttpClient.execute(CommandLineHttpClient.java:178) ~[?:?]
> 	at org.elasticsearch.xpack.core.security.CommandLineHttpClient.execute(CommandLineHttpClient.java:112) ~[?:?]
> 	at org.elasticsearch.xpack.security.tool.BaseRunAsSuperuserCommand.checkClusterHealthWithRetries(BaseRunAsSuperuserCommand.java:214) ~[?:?]
> 	at org.elasticsearch.xpack.security.tool.BaseRunAsSuperuserCommand.execute(BaseRunAsSuperuserCommand.java:127) ~[?:?]
> 	at org.elasticsearch.common.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:54) ~[elasticsearch-8.7.0.jar:8.7.0]
> 	at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:85) ~[elasticsearch-cli-8.7.0.jar:8.7.0]
> 	at org.elasticsearch.cli.Command.main(Command.java:50) ~[elasticsearch-cli-8.7.0.jar:8.7.0]
> 	at org.elasticsearch.launcher.CliToolLauncher.main(CliToolLauncher.java:64) ~[cli-launcher-8.7.0.jar:8.7.0]
> 
> ERROR: Failed to determine the health of the cluster.

Hi @Julien069 ! The issue is the machine you are trying to create the enrollment token from does not have the ability to establish a connection over SSL (https). This is an issue with the certificate not including your Elasticsearch node's address, how did you generate the SSL certificate? It should include a SAN (Subject Alternative Name) entry for your IP address see:

The alternative is to just not connect over SSL (xpack.security.http.ssl.enabled: false), but I'm not sure whether that is an option for you?

Hi Jean-louis ( French ? )

In fact , the problem comes from the change of the IP address .
I tried to generate a new CA but it doesn't work .

I don't understand somethings , what it's the difference between :

xpack.security.http.ssl

and

xpack.security.transport.ssl

For me ,http.ssl is for the webconsole and transport for the exchange between Elastic and Kibana ...

I see, it seems your ES node's public IP address changed.

Again, to get a new certificate from your Elasticsearch central CA follow the link from the previous message and use the ./bin/elasticsearch-certutil http (from where you have ES installed) and follow the prompts.

http is for any traffic coming to your cluster over the Internet, this includes Kibana. transport is for internode communication - traffic that flows between your ES nodes.

Thanks you very much for your help

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.