Renew auto generated http certificates

Elastic Stack Elasticsearch
1

Hello,

can anyone help me how to renew the http certificates of the elasticsearch nodes in a autoconfigured on-prem cluster?
The current ones were generated automatically from the enrollment process / at startup of the nodes and are now running out after 2 years.

I tried the docu under Update certificates with the same CA | Elasticsearch Guide [8.14] | Elastic but that didn't work because the http ca and cert are both in the same p12 file which the certutil is not supporting.

I also found Auto-configuration of ssl certificate - Elastic Stack / Elasticsearch - Discuss the Elastic Stack but the only answer is only talking about the transport certificates and does not mention the http certs. The transport certs are not the problem because these seem to be valid for a 100 years.

Thanks in advance
Christian

2

Hi @Shaoranlaos,

Thanks for sharing what you've tried. I found these steps for updating the HTTP certs. Have you tried those?

3

Yes thats the one I ment with the link in my question.
I have no elastic-stack-ca.p12 because the http certs where auto-generated and the http.p12 where the CA private key is included is not accepted by the the cert util.

Here is the output if i try that.

[root@els01 ~]# /usr/share/elasticsearch/bin/elasticsearch-certutil http

## Elasticsearch HTTP Certificate Utility

The 'http' command guides you through the process of generating certificates
for use on the HTTP (Rest) interface for Elasticsearch.

This tool will ask you a number of questions in order to generate the right
set of files for your needs.

## Do you wish to generate a Certificate Signing Request (CSR)?

A CSR is used when you want your certificate to be created by an existing
Certificate Authority (CA) that you do not control (that is, you don't have
access to the keys for that CA).

If you are in a corporate environment with a central security team, then you
may have an existing Corporate CA that can generate your certificate for you.
Infrastructure within your organisation may already be configured to trust this
CA, so it may be easier for clients to connect to Elasticsearch if you use a
CSR and send that request to the team that controls your CA.

If you choose not to generate a CSR, this tool will generate a new certificate
for you. That certificate will be signed by a CA under your control. This is a
quick and easy way to secure your cluster with TLS, but you will need to
configure all your clients to trust that custom CA.

Generate a CSR? [y/N]N

## Do you have an existing Certificate Authority (CA) key-pair that you wish to use to sign your certificate?

If you have an existing CA certificate and key, then you can use that CA to
sign your new http certificate. This allows you to use the same CA across
multiple Elasticsearch clusters which can make it easier to configure clients,
and may be easier for you to manage.

If you do not have an existing CA, one will be generated for you.

Use an existing CA? [y/N]y

## What is the path to your CA?

Please enter the full pathname to the Certificate Authority that you wish to
use for signing your new http certificate. This can be in PKCS#12 (.p12), JKS
(.jks) or PEM (.crt, .key, .pem) format.
CA Path: /etc/elasticsearch/certs/http.p12
Reading a PKCS12 keystore requires a password.
It is possible for the keystore's password to be blank,
in which case you can simply press <ENTER> at the prompt
Password for http.p12:
The keystore at /etc/elasticsearch/certs/http.p12 contains 2 keys,
but this command requires a keystore with a single key
Please try again with a keystore that contains exactly 1 private key entry

ERROR: The CA keystore /etc/elasticsearch/certs/http.p12 contains 2 keys
4

If you want to use the existing HTTP CA, then I suspect you're going to need to use a separate tool to extract the CA certificate and key from the http.p12.

Both openssl and Java's keytool (which ships with Elasticsearch) can do this.

With keytool, the simplest option is probably to create a new PKCS#12 keystore that only contains the CA. You can do that with:

keytool -importkeystore -srckeystore http.p12 -destkeystore http_ca.p12 -srcalias http_ca

It will prompt (twice) for a destination password. You can use the same password as the source (http.p12) or a new password, it doesn't matter.

Then you can use http_ca.p12 to generate a new server certificate.

However, your HTTP CA is probably due to expire in a year as well, so you'll need to go through the process of generating a whole new CA at that time.

Sorry, CA management for clients is a pain, and there's only so much we can do to make it easier. I'll look at making it possible to use the HTTP CA without having to extract it from the http.p12 keystore, but that only helps a little. Eventually you need to have a process to manage your own certificates (or switch to Elastic Cloud and let us manage it for you).

5

Thanks for this, it seems to have worked (couldn't yet test the generated certificate stores).

I also noticed that the corresponding CA is expiring in a year. I will have to see how i do the replacing of it next year because this CA is entered in all elastic products (Logstash, Beats, Agents, ...), so it will be a bit of a process (hadn't realised that it was limited to 3 years when i configured my cluster 2 years ago...).