- Elasticsearch Guide: other versions:
- Elasticsearch introduction
- Getting started with Elasticsearch
- Set up Elasticsearch
- Installing Elasticsearch
- Configuring Elasticsearch
- Setting JVM options
- Secure settings
- Logging configuration
- Auditing settings
- Cross-cluster replication settings
- Transforms settings
- Index lifecycle management settings
- License settings
- Machine learning settings
- Monitoring settings
- Security settings
- Snapshot lifecycle management settings
- SQL access settings
- Watcher settings
- Important Elasticsearch configuration
- Important System Configuration
- Bootstrap Checks
- Heap size check
- File descriptor check
- Memory lock check
- Maximum number of threads check
- Max file size check
- Maximum size virtual memory check
- Maximum map count check
- Client JVM check
- Use serial collector check
- System call filter check
- OnError and OnOutOfMemoryError checks
- Early-access check
- G1GC check
- All permission check
- Discovery configuration check
- Starting Elasticsearch
- Stopping Elasticsearch
- Adding nodes to your cluster
- Full-cluster restart and rolling restart
- Set up X-Pack
- Configuring X-Pack Java Clients
- Bootstrap Checks for X-Pack
- Upgrade Elasticsearch
- Aggregations
- Metrics Aggregations
- Avg Aggregation
- Weighted Avg Aggregation
- Cardinality Aggregation
- Extended Stats Aggregation
- Geo Bounds Aggregation
- Geo Centroid Aggregation
- Max Aggregation
- Min Aggregation
- Percentiles Aggregation
- Percentile Ranks Aggregation
- Scripted Metric Aggregation
- Stats Aggregation
- String Stats Aggregation
- Sum Aggregation
- Top Hits Aggregation
- Value Count Aggregation
- Median Absolute Deviation Aggregation
- Bucket Aggregations
- Adjacency Matrix Aggregation
- Auto-interval Date Histogram Aggregation
- Children Aggregation
- Composite aggregation
- Date histogram aggregation
- Date Range Aggregation
- Diversified Sampler Aggregation
- Filter Aggregation
- Filters Aggregation
- Geo Distance Aggregation
- GeoHash grid Aggregation
- GeoTile Grid Aggregation
- Global Aggregation
- Histogram Aggregation
- IP Range Aggregation
- Missing Aggregation
- Nested Aggregation
- Parent Aggregation
- Range Aggregation
- Rare Terms Aggregation
- Reverse nested Aggregation
- Sampler Aggregation
- Significant Terms Aggregation
- Significant Text Aggregation
- Terms Aggregation
- Subtleties of bucketing range fields
- Pipeline Aggregations
- Avg Bucket Aggregation
- Derivative Aggregation
- Max Bucket Aggregation
- Min Bucket Aggregation
- Sum Bucket Aggregation
- Stats Bucket Aggregation
- Extended Stats Bucket Aggregation
- Percentiles Bucket Aggregation
- Moving Average Aggregation
- Moving Function Aggregation
- Cumulative Sum Aggregation
- Cumulative Cardinality Aggregation
- Bucket Script Aggregation
- Bucket Selector Aggregation
- Bucket Sort Aggregation
- Serial Differencing Aggregation
- Matrix Aggregations
- Caching heavy aggregations
- Returning only aggregation results
- Aggregation Metadata
- Returning the type of the aggregation
- Indexing aggregation results with transforms
- Metrics Aggregations
- Query DSL
- Search across clusters
- Scripting
- Mapping
- Text analysis
- Overview
- Concepts
- Configure text analysis
- Built-in analyzer reference
- Tokenizer reference
- Char Group Tokenizer
- Classic Tokenizer
- Edge n-gram tokenizer
- Keyword Tokenizer
- Letter Tokenizer
- Lowercase Tokenizer
- N-gram tokenizer
- Path Hierarchy Tokenizer
- Path Hierarchy Tokenizer Examples
- Pattern Tokenizer
- Simple Pattern Tokenizer
- Simple Pattern Split Tokenizer
- Standard Tokenizer
- Thai Tokenizer
- UAX URL Email Tokenizer
- Whitespace Tokenizer
- Token filter reference
- Apostrophe
- ASCII folding
- CJK bigram
- CJK width
- Classic
- Common grams
- Conditional
- Decimal digit
- Delimited payload
- Dictionary decompounder
- Edge n-gram
- Elision
- Fingerprint
- Flatten graph
- Hunspell
- Hyphenation decompounder
- Keep types
- Keep words
- Keyword marker
- Keyword repeat
- KStem
- Length
- Limit token count
- Lowercase
- MinHash
- Multiplexer
- N-gram
- Normalization
- Pattern capture
- Pattern replace
- Phonetic
- Porter stem
- Predicate script
- Remove duplicates
- Reverse
- Shingle
- Snowball
- Stemmer
- Stemmer override
- Stop
- Synonym
- Synonym graph
- Trim
- Truncate
- Unique
- Uppercase
- Word delimiter
- Word delimiter graph
- Character filters reference
- Normalizers
- Modules
- Index modules
- Ingest node
- Pipeline Definition
- Accessing Data in Pipelines
- Conditional Execution in Pipelines
- Handling Failures in Pipelines
- Enrich your data
- Processors
- Append Processor
- Bytes Processor
- Circle Processor
- Convert Processor
- CSV Processor
- Date Processor
- Date Index Name Processor
- Dissect Processor
- Dot Expander Processor
- Drop Processor
- Enrich Processor
- Fail Processor
- Foreach Processor
- GeoIP Processor
- Grok Processor
- Gsub Processor
- HTML Strip Processor
- Inference Processor
- Join Processor
- JSON Processor
- KV Processor
- Lowercase Processor
- Pipeline Processor
- Remove Processor
- Rename Processor
- Script Processor
- Set Processor
- Set Security User Processor
- Split Processor
- Sort Processor
- Trim Processor
- Uppercase Processor
- URL Decode Processor
- User Agent processor
- ILM: Manage the index lifecycle
- SQL access
- Overview
- Getting Started with SQL
- Conventions and Terminology
- Security
- SQL REST API
- SQL Translate API
- SQL CLI
- SQL JDBC
- SQL ODBC
- SQL Client Applications
- SQL Language
- Functions and Operators
- Comparison Operators
- Logical Operators
- Math Operators
- Cast Operators
- LIKE and RLIKE Operators
- Aggregate Functions
- Grouping Functions
- Date/Time and Interval Functions and Operators
- Full-Text Search Functions
- Mathematical Functions
- String Functions
- Type Conversion Functions
- Geo Functions
- Conditional Functions And Expressions
- System Functions
- Reserved keywords
- SQL Limitations
- Monitor a cluster
- Frozen indices
- Roll up or transform your data
- Set up a cluster for high availability
- Snapshot and restore
- Secure a cluster
- Overview
- Configuring security
- User authentication
- Built-in users
- Internal users
- Token-based authentication services
- Realms
- Realm chains
- Active Directory user authentication
- File-based user authentication
- LDAP user authentication
- Native user authentication
- OpenID Connect authentication
- PKI user authentication
- SAML authentication
- Kerberos authentication
- Integrating with other authentication systems
- Enabling anonymous access
- Controlling the user cache
- Configuring SAML single-sign-on on the Elastic Stack
- Configuring single sign-on to the Elastic Stack using OpenID Connect
- User authorization
- Built-in roles
- Defining roles
- Security privileges
- Document level security
- Field level security
- Granting privileges for indices and aliases
- Mapping users and groups to roles
- Setting up field and document level security
- Submitting requests on behalf of other users
- Configuring authorization delegation
- Customizing roles and authorization
- Enabling audit logging
- Encrypting communications
- Restricting connections with IP filtering
- Cross cluster search, clients, and integrations
- Tutorial: Getting started with security
- Tutorial: Encrypting communications
- Troubleshooting
- Some settings are not returned via the nodes settings API
- Authorization exceptions
- Users command fails due to extra arguments
- Users are frequently locked out of Active Directory
- Certificate verification fails for curl on Mac
- SSLHandshakeException causes connections to fail
- Common SSL/TLS exceptions
- Common Kerberos exceptions
- Common SAML issues
- Internal Server Error in Kibana
- Setup-passwords command fails due to connection failure
- Failures due to relocation of the configuration files
- Limitations
- Alerting on cluster and index events
- Command line tools
- How To
- Glossary of terms
- REST APIs
- API conventions
- cat APIs
- Cluster APIs
- Cross-cluster replication APIs
- Document APIs
- Enrich APIs
- Explore API
- Index APIs
- Add index alias
- Analyze
- Clear cache
- Clone index
- Close index
- Create index
- Delete index
- Delete index alias
- Delete index template
- Flush
- Force merge
- Freeze index
- Get field mapping
- Get index
- Get index alias
- Get index settings
- Get index template
- Get mapping
- Index alias exists
- Index exists
- Index recovery
- Index segments
- Index shard stores
- Index stats
- Index template exists
- Open index
- Put index template
- Put mapping
- Refresh
- Rollover index
- Shrink index
- Split index
- Synced flush
- Type exists
- Unfreeze index
- Update index alias
- Update index settings
- Index lifecycle management API
- Ingest APIs
- Info API
- Licensing APIs
- Machine learning anomaly detection APIs
- Add events to calendar
- Add jobs to calendar
- Close jobs
- Create jobs
- Create calendar
- Create datafeeds
- Create filter
- Delete calendar
- Delete datafeeds
- Delete events from calendar
- Delete filter
- Delete forecast
- Delete jobs
- Delete jobs from calendar
- Delete model snapshots
- Delete expired data
- Find file structure
- Flush jobs
- Forecast jobs
- Get buckets
- Get calendars
- Get categories
- Get datafeeds
- Get datafeed statistics
- Get influencers
- Get jobs
- Get job statistics
- Get machine learning info
- Get model snapshots
- Get overall buckets
- Get scheduled events
- Get filters
- Get records
- Open jobs
- Post data to jobs
- Preview datafeeds
- Revert model snapshots
- Set upgrade mode
- Start datafeeds
- Stop datafeeds
- Update datafeeds
- Update filter
- Update jobs
- Update model snapshots
- Machine learning data frame analytics APIs
- Create data frame analytics jobs
- Create inference trained model
- Delete data frame analytics jobs
- Delete inference trained model
- Evaluate data frame analytics
- Explain data frame analytics API
- Get data frame analytics jobs
- Get data frame analytics jobs stats
- Get inference trained model
- Get inference trained model stats
- Start data frame analytics jobs
- Stop data frame analytics jobs
- Migration APIs
- Reload search analyzers
- Rollup APIs
- Search APIs
- Security APIs
- Authenticate
- Change passwords
- Clear cache
- Clear roles cache
- Create API keys
- Create or update application privileges
- Create or update role mappings
- Create or update roles
- Create or update users
- Delegate PKI authentication
- Delete application privileges
- Delete role mappings
- Delete roles
- Delete users
- Disable users
- Enable users
- Get API key information
- Get application privileges
- Get builtin privileges
- Get role mappings
- Get roles
- Get token
- Get users
- Has privileges
- Invalidate API key
- Invalidate token
- OpenID Connect Prepare Authentication API
- OpenID Connect authenticate API
- OpenID Connect logout API
- SAML prepare authentication API
- SAML authenticate API
- SAML logout API
- SAML invalidate API
- SSL certificate
- Snapshot and restore APIs
- Snapshot lifecycle management API
- Transform APIs
- Usage API
- Watcher APIs
- Definitions
- Release highlights
- Breaking changes
- Release notes
- Elasticsearch version 7.6.2
- Elasticsearch version 7.6.1
- Elasticsearch version 7.6.0
- Elasticsearch version 7.5.2
- Elasticsearch version 7.5.1
- Elasticsearch version 7.5.0
- Elasticsearch version 7.4.2
- Elasticsearch version 7.4.1
- Elasticsearch version 7.4.0
- Elasticsearch version 7.3.2
- Elasticsearch version 7.3.1
- Elasticsearch version 7.3.0
- Elasticsearch version 7.2.1
- Elasticsearch version 7.2.0
- Elasticsearch version 7.1.1
- Elasticsearch version 7.1.0
- Elasticsearch version 7.0.0
- Elasticsearch version 7.0.0-rc2
- Elasticsearch version 7.0.0-rc1
- Elasticsearch version 7.0.0-beta1
- Elasticsearch version 7.0.0-alpha2
- Elasticsearch version 7.0.0-alpha1
Encrypting communications in Elasticsearch
editEncrypting communications in Elasticsearch
editElastic Stack security features enable you to encrypt traffic to, from, and within your Elasticsearch cluster. Connections are secured using Transport Layer Security (TLS/SSL).
Clusters that do not have encryption enabled send all data in plain text including passwords. If the Elasticsearch security features are enabled, unless you have a trial license, you must configure SSL/TLS for internode-communication.
To enable encryption, you need to perform the following steps on each node in the cluster:
-
Verify that the
xpack.security.enabled
setting istrue
. For more information, see Security settings. - Generate a private key and X.509 certificate.
-
Configure each node to:
- Required: Enable TLS on the transport layer.
- Recommended: Enable TLS on the HTTP layer.
- If you are using Active Directory user authentication, encrypt communications between Elasticsearch and your Active Directory server.
- If you are using LDAP user authentication, encrypt communications between Elasticsearch and your LDAP server.
For more information about encrypting communications across the Elastic Stack, see Encrypting communications.
Generating node certificates
editTLS requires X.509 certificates to perform encryption and authentication of the application that is being communicated with. In order for the communication between nodes to be truly secure, the certificates must be validated. The recommended approach for validating certificate authenticity in an Elasticsearch cluster is to trust the certificate authority (CA) that signed the certificate. By doing this, as nodes are added to your cluster they just need to use a certificate signed by the same CA and the node is automatically allowed to join the cluster. Additionally, it is recommended that the certificates contain subject alternative names (SAN) that correspond to the node’s IP address and DNS name so that hostname verification can be performed.
The elasticsearch-certutil
command simplifies the process
of generating certificates for the Elastic Stack. It takes care of generating a CA and
signing certificates with the CA. It can be used interactively or in a silent
mode through the use of an input file. It also supports generation of
certificate signing requests (CSR), so that a commercial- or
organization-specific CA can be used to sign the certificates. For example:
-
Optional: Create a certificate authority for your Elasticsearch cluster.
For example, use the
elasticsearch-certutil ca
command:bin/elasticsearch-certutil ca
You can configure the cluster to trust all nodes that have a certificate that has been signed by this CA.
The command outputs a single file, with a default name of
elastic-stack-ca.p12
. This file is a PKCS#12 keystore that contains the public certificate for your CA and the private key that is used to sign the certificates for each node.The
elasticsearch-certutil
command also prompts you for a password to protect the file and key. If you plan to add more nodes to your cluster in the future, retain a copy of the file and remember its password. -
Generate a certificate and private key for each node in your cluster.
For example, use the
elasticsearch-certutil cert
command:bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
The output is a single PKCS#12 keystore that includes the node certificate, node key, and CA certificate.
You are also prompted for a password. You can enter a password for your certificate and key, or you can leave the password blank by pressing Enter.
By default
elasticsearch-certutil
generates certificates that have no hostname information in them (that is, they do not have any Subject Alternative Name fields). This means that you can use the certificate for every node in your cluster, but you must turn off hostname verification as shown in the configuration below.If you want to use hostname verification within your cluster, run the
elasticsearch-certutil cert
command once for each of your nodes and provide the--name
,--dns
and--ip
options.You should secure the output files, since they contain the private keys for your instance.
Alternatively, if you want to use a commercial or organization-specific CA, you can use the
elasticsearch-certutil csr
command to generate certificate signing requests (CSR) for the nodes in your cluster. For more information, see elasticsearch-certutil. -
Optional: Generate additional certificates specifically for encrypting HTTP client communications.
For example, use the
elasticsearch-certutil http
command:bin/elasticsearch-certutil http
This command guides you through the process of generating the appropriate certificates for use in Elasticsearch and Kibana. If you created a CA for your cluster, you can re-use it by supplying its location when prompted.
-
Copy the node certificates to the appropriate locations.
Copy the applicable files into the Elasticsearch configuration directory on each node.
For each additional Elastic product that you want to configure, copy the certificates to the relevant configuration directory.
If you choose not to use elasticsearch-certutil
, the certificates that
you obtain must allow for both clientAuth
and serverAuth
if the extended key
usage extension is present. The certificates need to be in PEM or PKCS#12
format. Although not required, it is highly recommended that the certificate
contain the DNS names and/or IP addresses of the node so that hostname
verification can be used.
Encrypting communications between nodes in a cluster
editThe transport networking layer is used for internal communication between nodes in a cluster. When security features are enabled, you must use TLS to ensure that communication between the nodes is encrypted.
- Generate node certificates.
-
Enable TLS and specify the information required to access the node’s certificate.
-
If the signed certificate is in PKCS#12 format, add the following information to the
elasticsearch.yml
file on each node: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
If you used the
--dns
or--ip
options with theelasticsearch-certutil cert
command and you want to enable strict hostname checking, set the verification mode tofull
. For a description of these values, see Transport TLS/SSL settings.If you created a separate certificate for each node, then you might need to customize this path on each node. If the filename matches the node name, you can use the
${node.name}.p12
format, for example.The
elasticsearch-certutil
outputs a PKCS#12 keystore which includes the CA certificate as a trusted certificate entry. This allows for the keystore to also be used as a truststore. In this case, the path value should match thekeystore.path
value. Note, however, that this is not the general rule. There are keystores that cannot be used as truststores, only specifically crafted ones can -
If the certificate is in PEM format, add the following information to the
elasticsearch.yml
file on each node:xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.key: /home/es/config/node01.key xpack.security.transport.ssl.certificate: /home/es/config/node01.crt xpack.security.transport.ssl.certificate_authorities: [ "/home/es/config/ca.crt" ]
If you used the
--dns
or--ip
options with theelasticsearch-certutil cert
command and you want to enable strict hostname checking, set the verification mode tofull
. For a description of these values, see Transport TLS/SSL settings.The full path to the node key file. This must be a location within the Elasticsearch configuration directory.
The full path to the node certificate. This must be a location within the Elasticsearch configuration directory.
An array of paths to the CA certificates that should be trusted. These paths must be a location within the Elasticsearch configuration directory.
-
-
If you secured the node’s certificate with a password, add the password to your Elasticsearch keystore:
-
If the signed certificate is in PKCS#12 format, use the following commands:
bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password
-
If the certificate is in PEM format, use the following commands:
bin/elasticsearch-keystore add xpack.security.transport.ssl.secure_key_passphrase
-
-
Restart Elasticsearch.
You must perform a full cluster restart. Nodes which are configured to use TLS cannot communicate with nodes that are using unencrypted networking (and vice-versa). After enabling TLS you must restart all nodes in order to maintain communication across the cluster.
- All TLS-related node settings are considered to be highly sensitive and therefore are not exposed via the nodes info API For more information about any of these settings, see Security settings.
-
Elasticsearch monitors all files such as certificates, keys, keystores, or truststores
that are configured as values of TLS-related node settings. If you update any of
these files (for example, when your hostnames change or your certificates are
due to expire), Elasticsearch reloads them. The files are polled for changes at
a frequency determined by the global Elasticsearch
resource.reload.interval.high
setting, which defaults to 5 seconds.
Encrypting HTTP client communications
editWhen security features are enabled, you can optionally use TLS to ensure that communication between HTTP clients and the cluster is encrypted.
Enabling TLS on the HTTP layer is strongly recommended but is not required. If you enable TLS on the HTTP layer in Elasticsearch, then you might need to make configuration changes in other parts of the Elastic Stack and in any Elasticsearch clients that you use.
-
If you have not done so already, generate node certificates.
In particular, you need the files that are generated by the following command:
bin/elasticsearch-certutil http
This command generates a zip file that contains certificates and keys for use in Elasticsearch and Kibana. Each folder contains a readme that explains how to use the files.
-
Verify that you’ve copied the output files to the appropriate locations, as specified in the readme files.
For example, copy the
http.p12
file from theelasticsearch
folder into a directory within the Elasticsearch configuration directory on each node. If you chose to generate one certificate per node, copy the appropriatehttp.p12
file to each node. If you want to use Kibana to access this cluster, copy theelasticsearch-ca.pem
file from thekibana
folder into the Kibana configuration directory. -
Enable TLS and specify the information required to access the node’s certificate. For example:
-
Update the
elasticsearch.yml
file on each node with the location of the certificates.If the certificates are in PKCS#12 format:
xpack.security.http.ssl.enabled: true xpack.security.http.ssl.keystore.path: "http.p12"
If you have certificates in PEM format:
xpack.security.http.ssl.enabled: true xpack.security.http.ssl.key: /home/es/config/node1_http.key xpack.security.http.ssl.certificate: /home/es/config/node1_http.crt xpack.security.http.ssl.certificate_authorities: [ "/home/es/config/ca.crt" ]
The full path to the node key file. This must be a location within the Elasticsearch configuration directory.
The full path to the node certificate. This must be a location within the Elasticsearch configuration directory.
An array of paths to the CA certificates that should be trusted. These paths must be a location within the Elasticsearch configuration directory.
-
If you secured the keystore or the private key with a password, add that password to a secure setting in Elasticsearch.
If the certificates are in PKCS#12 format:
bin/elasticsearch-keystore add xpack.security.http.ssl.keystore.secure_password
If the certificates are in PEM format:
bin/elasticsearch-keystore add xpack.security.http.ssl.secure_key_passphrase
-
-
Optional: If you want to use Kibana, follow the instructions in the readme
provided by the
elasticsearch-certutil http
command or see Encrypting communications in Kibana. - Restart Elasticsearch.
- All TLS-related node settings are considered to be highly sensitive and therefore are not exposed via the nodes info API For more information about any of these settings, see Security settings.
-
Elasticsearch monitors all files such as certificates, keys, keystores, or truststores
that are configured as values of TLS-related node settings. If you update any of
these files (for example, when your hostnames change or your certificates are
due to expire), Elasticsearch reloads them. The files are polled for changes at
a frequency determined by the global Elasticsearch
resource.reload.interval.high
setting, which defaults to 5 seconds.
Encrypting communications between Elasticsearch and Active Directory
editTo protect the user credentials that are sent for authentication, it’s highly recommended to encrypt communications between Elasticsearch and your Active Directory server. Connecting via SSL/TLS ensures that the identity of the Active Directory server is authenticated before Elasticsearch transmits the user credentials and the usernames and passwords are encrypted in transit.
Clients and nodes that connect via SSL/TLS to the Active Directory server need to have the Active Directory server’s certificate or the server’s root CA certificate installed in their keystore or truststore.
-
Create the realm configuration for the
xpack.security.authc.realms
namespace in theelasticsearch.yml
file. See Configuring an Active Directory realm. -
Set the
url
attribute in the realm configuration to specify the LDAPS protocol and the secure port number. For example,url: ldaps://ad.example.com:636
. -
Configure each node to trust certificates signed by the certificate authority (CA) that signed your Active Directory server certificates.
The following example demonstrates how to trust a CA certificate (
cacert.pem
), which is located within the configuration directory:xpack: security: authc: realms: active_directory: ad_realm: order: 0 domain_name: ad.example.com url: ldaps://ad.example.com:636 ssl: certificate_authorities: [ "ES_PATH_CONF/cacert.pem" ]
The CA cert must be a PEM encoded certificate.
For more information about these settings, see Active Directory realm settings.
- Restart Elasticsearch.
By default, when you configure Elasticsearch to connect to Active Directory
using SSL/TLS, it attempts to verify the hostname or IP address
specified with the url
attribute in the realm configuration with the
values in the certificate. If the values in the certificate and realm
configuration do not match, Elasticsearch does not allow a connection to the
Active Directory server. This is done to protect against man-in-the-middle
attacks. If necessary, you can disable this behavior by setting the
ssl.verification_mode
property to certificate
.
Encrypting communications between Elasticsearch and LDAP
editTo protect the user credentials that are sent for authentication in an LDAP realm, it’s highly recommended to encrypt communications between Elasticsearch and your LDAP server. Connecting via SSL/TLS ensures that the identity of the LDAP server is authenticated before Elasticsearch transmits the user credentials and the contents of the connection are encrypted. Clients and nodes that connect via TLS to the LDAP server need to have the LDAP server’s certificate or the server’s root CA certificate installed in their keystore or truststore.
For more information, see LDAP user authentication.
-
Configure the realm’s TLS settings on each node to trust certificates signed by the CA that signed your LDAP server certificates. The following example demonstrates how to trust a CA certificate,
cacert.pem
, located within the Elasticsearch configuration directory (ES_PATH_CONF):xpack: security: authc: realms: ldap: ldap1: order: 0 url: "ldaps://ldap.example.com:636" ssl: certificate_authorities: [ "ES_PATH_CONF/cacert.pem" ]
The CA certificate must be a PEM encoded.
You can also specify the individual server certificates rather than the CA certificate, but this is only recommended if you have a single LDAP server or the certificates are self-signed.
-
Set the
url
attribute in the realm configuration to specify the LDAPS protocol and the secure port number. For example,url: ldaps://ldap.example.com:636
. - Restart Elasticsearch.
By default, when you configure Elasticsearch to connect to an LDAP server
using SSL/TLS, it attempts to verify the hostname or IP address
specified with the url
attribute in the realm configuration with the
values in the certificate. If the values in the certificate and realm
configuration do not match, Elasticsearch does not allow a connection to the
LDAP server. This is done to protect against man-in-the-middle attacks. If
necessary, you can disable this behavior by setting the
ssl.verification_mode
property to certificate
.
On this page