Hi Team,
We are running elastic cluster from past 8 years and tls certificate is expiring. The current certificate i don't know the password and i don't know the CA certificate it is using.
Can i create new TLS certificate with new CA . Will it effects the node communication if we replace the older with new certificate ? do we need to mention CA details in kibana.yml . Please advise any challenge i will get if use new certificate,
Yes, you can create a new TLS certificate with a new CA. But replacing the old cert without coordinating updates on all nodes will break node-to-node communication until all nodes trust the new CA. You’ll also need to update elasticsearch.hosts and elasticsearch.ssl.certificateAuthorities in kibana.yml to point to the new CA. Make sure to plan for a rolling update and test in a staging setup first.
You will need to replace the CA and regenerate the certificate for all nodes, this documentation may help you as it has the steps required.
You will also need to update the new ca in kibana.yml as well.
One issue you may have is that your cluster may be unavailable during this process.
Yes, you can use a new TLS certificate with a new CA, but all Elasticsearch nodes and Kibana must trust the new CA.
Update their truststores and kibana.yml. Replace certificates node-by-node using a rolling restart to avoid downtime and ensure cluster communication continues.
Which certificate you have rn?
I have 12 nodes of Elasticsearch cluster where i need to replace the tls certificate .I have generated ca certificate and tls certificate , replaced the tls certificate mentioned in elaticsearch.yml and restart the one node but service was got failed . I haven’t done the changes on kibana.
Existing certificate will expire on October 2025. But if i change certificate for one node it has to work. If I replace certificate in all nodes then cluster will go to red state.
Obviously you need to tread carefully to avoid downtime, so we can be more helpful if you share the specifics of what you have done, what your current configuration is, and what new files you have used and how (i.e. did you overwrite existing files?).
Note you mentioned the cluster has been running for 8 years, and kudos to you for this, but I guess it's same cluster you mentioned in another recent thread, around disk usage getting to 100%, when you manually deleted files within the data.path. Please take a more cautious, careful, measured approach if you want to avoid downtime/problems.
There's a useful endpoint, do a GET on https://YOUR_ES_HOST:9200/_ssl/certificates for each of your hosts, and you can check things as you go (and establish the starting point).
You could setup a small (3-node?) test cluster using VMs to practice the process. Use the autogenerated CA/certs to begin with, then use your own CA and new certs and migrate that cluster. You've got time learn how to do it right, your current certs dont expire for 3 months.
Hello Everyone,
I have performed below steps till now.
1. bin/elasticsearch-certutil ca --days 4000 days --keysize 4096 --pem
2. unzip elastic-stack-ca.zip
3. keytool -importcert -trustcacerts -noprompt -keystore elastic-stack-ca.p12 -storepass xxxxx -alias new-ca -file ca/ca.crt
4. keytool -keystore elastic-stack-ca.p12 -list
5. Downloaded elastic-stack-ca.p12 and ca/ca.crt and ca/ca.key into local system
6. login to each elastic server move elastic-stack-ca.p12 and ca/ca.crt and ca/ca.key from local
7. keytool -keystore elastic-stack-ca.p12 -list(run keytool command and verified new ca was listed)
8. Run bin/elasticsearch-certutil cert --ca-cert ca/ca.crt --ca-key ca/ca.key in coordinate node
9. cp -pvr elastic-* /etc/elasticsearch/certs/
10. chmod 777 /etc/elasticsearch/certs/elastic-*
11. modify elasticsearch.yml
12. Rolling restart your nodes.
Elasticsearch.yml
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.supported_protocols: ["TLSv1.2", "TLSv1.3"]
xpack.security.transport.ssl.cipher_suites: ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"]
xpack.security.transport.ssl.verification_mode: certificate
#old tls certificate
#xpack.security.transport.ssl.keystore.path: certs/es-transport.p12
#xpack.security.transport.ssl.truststore.path: certs/es-transport.p12
#new tls certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12
When i restarted one node i was getting below error .
Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:157) ~[?:?]
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:83) ~[?:?]
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) ~[?:?]
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:313) ~[?:?]
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:267) ~[?:?]
at sun.security.validator.Validator.validate(Validator.java:256) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:284) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:144) ~[?:?]
at org.elasticsearch.common.ssl.DiagnosticTrustManager.checkServerTrusted(DiagnosticTrustManager.java:101) ~[?:?]
at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:629) ~[?:?]
at sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:471) ~[?:?]
at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:367) ~[?:?]
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:393) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:476) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1274) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1260) ~[?:?]
at java.security.AccessController.doPrivileged(AccessController.java:714) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1205) ~[?:?]
at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1691) ~[?:?]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1537) ~[?:?]
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1378) ~[?:?]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1427) ~[?:?]
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) ~[?:?]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) ~[?:?]
... 16 more
[2025-07-03T14:46:20,777][WARN ][o.e.c.s.DiagnosticTrustManager] [yonodrwaflogkiban1] failed to establish trust with server at [<unknown host>]; the server provided a certificate with subject name [CN=es-ops], fingerprint [4988f32db9603163e21f7527e2c1a5de08b35f4d], no keyUsage and no extendedKeyUsage; the certificate is valid between [2022-10-20T12:25:42Z] and [2025-10-19T12:25:42Z] (current time is [2025-07-03T09:16:20.777012799Z], certificate dates are valid); the session uses cipher suite [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384] and protocol [TLSv1.2]; the certificate does not have any subject alternative names; the certificate is issued by [CN=Elastic Certificate Tool Autogenerated CA]; the certificate is signed by (subject [CN=Elastic Certificate Tool Autogenerated CA] fingerprint [662eeb1b3470ccf3d9e05ee22640c60d9c6cb25e]) which is self-issued; the [CN=Elastic Certificate Tool Autogenerated CA] certificate is not trusted in this ssl context ([xpack.security.transport.ssl (with trust configuration: StoreTrustConfig{path=certs/elastic-certificates.p12, password=<non-empty>, type=PKCS12, algorithm=PKIX})]); this ssl context does trust a certificate with subject [CN=Elastic Certificate Tool Autogenerated CA] but the trusted certificate has fingerprint [8e0ecfe5398e0173845edc04bf63088bdd999e4e]
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
What i can do next
Based on your situation and the error logs, here's a clear path forward.
The error Path does not chain with any of the trust anchors indicates that your new certificates aren't trusted by existing nodes. This happens because:
A full cluster restart is necessary cause you don't have the old CA credentials.
To Perform Full Cluster Restart:
# Step 1: Stop ALL Elasticsearch nodes simultaneously
sudo systemctl stop elasticsearch
# Step 2: Start ALL nodes within 5 minutes
sudo systemctl start elasticsearch
In kibana.yml:
elasticsearch.ssl.certificateAuthorities: ["/path/to/new/ca.crt"]
elasticsearch.ssl.verificationMode: certificate
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.