In terms of actual certificates, you can't. There's no practical way to reissue a certificate with a different CA.
You can reuse the underlying key to generate a CSR (although not with
certutil, you'd have to use
openssl), but I don't think that would have any practical benefit.
That other was to answer your question is When I get new certificates how do I switch to them?, which depends a little bit on your setup.
Technically, it's just a matter of switching things in
elasticsearch.yml, but if you have clients connecting, then they need to be prepared for the change, and if you are switching your internode (
transport.ssl) certificates, then you either need a full restart, or a planned out migration path to upgrade using rolling restarts.
There's actually 3 set of certificates:
- Certificates that the Elasticsearch nodes use to connect to each other (
- Certificates that the Elasticsearch nodes use for the REST API (
- Certificates that Kibana uses for its UI & API (in
For (1) we strongly recommend that you use a dedicated CA specifically for that purpose. It provids the strongest protections about cluster membership.
For (2) and (3) it can be helpful to use a third party CA (either a public CA or an internal corporate CA) so that you minimise the amount of trust config that your clients (web browsers and ES Rest clients) need.
It depends on what sort of Load-Balancer you use
If your load balancer operates at the http/s level (an "Application Load Balancer" or "Layer 7 Load Balancer" or "Reverse Proxy") then it will terminate the TLS connection itself and as far as the browsers are concerned, it's the certificate installed into the Load Balancer that matters.
You will need to decide what the TLS connection between the load balancer and Kibana will look like and for that, you can use a single cert with 2 DNS SANs, but there are other options, depending on what your load balancer supports.
If your load balancer operates at the TCP/IP level (a "Network Load Balancer" or "Layer 4 Load Balancer") then it will just route packets to the Kibana servers directly, and each Kibana server will need to have a certificate with a SAN that matches the FQDN that your users use to connect (like
kibana.xxx.xx) - as far as the web browsers are concerned there's only 1 server to talk to, so each Kibana needs to act like it's that server on that shared URL.