Built for Elasticsearch and Kibana
Pre-built Elasticsearch and Kibana templates ship in your CertKit account. No scripting required.
Elasticsearch and Kibana read their HTTPS certificates from PEM files named in
elasticsearch.yml and kibana.yml. A renewal has to land at those
exact paths, readable by the service account, on every node.
Every 47 days.
CertKit issues and renews the certificate centrally, then the CertKit Agent writes the files with the right permissions and restarts the service.
Pre-built Elasticsearch and Kibana templates ship in your CertKit account. No scripting required.
For Elasticsearch, the agent writes the certificate and key, sets their group to
elasticsearch with mode 0640, and restarts the service. For
Kibana, it writes the files so the Kibana service can read them, then restarts Kibana.
Run an agent on each node. Give each node its own deployment window so they don't all restart at once.
The manual process, if you want to do it yourself:
/etc/elasticsearch/certs is typical.
xpack.security.http.ssl.certificate and .key in elasticsearch.yml, and server.ssl.certificate and server.ssl.key in kibana.yml.
elasticsearch group must read the key on each node, and the Kibana user must read Kibana's.
Every one of these steps is manual, and Elastic won't repeat any of them when the certificate renews. With lifetimes shrinking to 47 days, that's twelve times a year, on every node. Miss one node and Kibana, Beats, and your apps start failing with certificate errors when they reach it.
At 47 days, automation is the only sustainable way to run Elasticsearch and Kibana certificates. Here's how CertKit does it.
Your Elastic node CertKit ACME CA ┌───────────────────┐ ┌──────────────────┐ ┌─────────────┐ │ │ │ │ │ │ │ ┌───────────────┐ │ Issue & Renew │◄──►│ │ │ │ CertKit Agent │◄──┤ Certificates │ │ │ │ └─────────┬─┬───┘ │ ┌───┐ └─────────────┘ │ │ │ │ └───────────┬────│DNS│ │ PEM files ◄─┘ │ │ │ └───┘ │ [x] Written │ │ │ │ │ │ │ │ Service ◄─┘ │ ◄───────────────┘ │ [x] Restarted │ Verify └───────────────────┘
CertKit issues and renews certificates centrally using delegated DNS validation. You create a one-time CNAME record, and CertKit handles every ACME challenge after that.
The agent on each node pulls renewals over outbound HTTPS and works locally. The cluster never runs ACME and never holds DNS credentials.
From an operational perspective, CertKit is easy to deploy and manage. The ability to configure unique and specialized certificates is key to replacing our manual certificate processes.
Laura Thomas, Senior Central Systems Administrator, University of St. Thomas
elasticsearch group with 0640 on search nodes, readable by Kibana on Kibana hosts.
elasticsearch-certutil is a good fit for the transport layer between nodes,
which only the cluster has to trust. The HTTP layer is different. Browsers, Kibana, Beats, and
your apps all connect to it, and a self-made CA means installing that CA on every one of
them.
A publicly trusted certificate on the HTTP layer avoids that, and CertKit keeps it renewed. Leave transport on certutil.
Most infrastructures have more than one place where certificates live: nginx in front of Kibana, Kubernetes clusters shipping logs, and Node.js apps under PM2. CertKit automates all of it from one account.
Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.