What impact will the SSL certificate expiration in the file elastic-certificates.p12 have?

Elastic Stack Elasticsearch
1

Version: 7.5.2
License: basic

configuration about security in elasticsearch.yml

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

return value of _ssl/certificates

{
    "path" : "elastic-certificates.p12",
    "format" : "PKCS12",
    "alias" : "instance",
    "subject_dn" : "CN=instance",
    "serial_number" : "c8ba591ea0914557872250f90fd1e17329962065",
    "has_private_key" : true,
    "expiry" : "2022-11-06T02:50:22.000Z"
  },
  {
    "path" : "elastic-certificates.p12",
    "format" : "PKCS12",
    "alias" : "instance",
    "subject_dn" : "CN=Elastic Certificate Tool Autogenerated CA",
    "serial_number" : "2296475b541947a75390e78dd50e7fc28194890a",
    "has_private_key" : false,
    "expiry" : "2022-11-06T02:50:22.000Z"
  },
  {
    "path" : "elastic-certificates.p12",
    "format" : "PKCS12",
    "alias" : "ca",
    "subject_dn" : "CN=Elastic Certificate Tool Autogenerated CA",
    "serial_number" : "2296475b541947a75390e78dd50e7fc28194890a",
    "has_private_key" : false,
    "expiry" : "2022-11-06T02:50:22.000Z"
  }

My ES cluster is configured with SSL encryption for internode communication, without encryption at the HTTP layer. I just realized today that my SSL certificate has expired. I checked the certificate validity through _ssl/certificates and found that it has been expired for over a year, but the cluster is still running normally. I want to know what impact an expired certificate will have on the cluster. Will it result in future unavailability or the inability to perform encrypted communication?

2

With expired certicates you cannot add new nodes and if one node goes down, it won't be able to come back until the certificate is fixed.

So, it may lead to your cluster being unavailable.

3

As Leandro said, SSL handshake will not be established simply because the certificate cannot be verified.
You can temporarily set xpack.security.transport.ssl.verification_mode: none which will not validate the certificate.
Of course, the best solution is renew/reissue the cert.

4

However, in reality, I have been using this expired certificate all along and have not encountered any issues. I can still restart nodes, add new nodes, and even create a new cluster without any problems. What could be the reason for this? Does the expiration of the certificate not affect internode communication?

5

I conducted another test. Even if I set "ssl.verification_mode" to "certificate", I can still use an expired PKCS#12 file configuration like this:

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

However, if I convert this certificate into three files: tls.crt, tls.key, ca.crt, and use the following configuration, I will encounter a certificate expiration error during startup, and the cluster will not run properly:

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.certificate: tls.crt
xpack.security.transport.ssl.certificate_authorities: ca.crt
xpack.security.transport.ssl.key: tls.key

Does it mean that the first PKCS#12 method of configuring certificates does not verify the certificate expiration time?
Alternatively, is this a bug?

6

The cluster runs as you set.

> xpack.security.transport.ssl.verification_mode

(Static) Defines how to verify the certificates presented by another party in the TLS connection:

Valid values

full
Validates that the provided certificate: has an issue date that’s within the not_before and not_after dates; chains to a trusted Certificate Authority (CA); has a hostname or IP address that matches the names within the certificate.
certificate
Validates the provided certificate and verifies that it’s signed by a trusted authority (CA), but doesn’t check the certificate hostname.
none

Performs no certificate validation.

Setting certificate validation to none disables many security benefits of SSL/TLS, which is very dangerous. Only set this value if instructed by Elastic Support as a temporary diagnostic mechanism when attempting to resolve TLS errors.

Defaults to full.

For details check here.

7

But why is it that when both are set to xpack.security.transport.ssl.verification_mode: certificate, the first method (using a .p12 file) does not check the expiration time of the certificate, while the second method does? Is there any documentation explaining this?

I am currently using the first method, and the certificate has already expired, but the system is running normally. I am concerned whether there will be any issues in the future.

8

Read the last sentence, click on the link.

9

Sorry I didn't understand the point you made. I know that I can set it to "none" to make es not check the validity of the certificate. But my question is why when setting it to "certificate", why setting the ssl.keystore.path parameter works normally, while setting ssl.certificate prompts the certificate to expire. There seems to be no explanation in the documentation for this issue.

10

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