# Empty file path for plugins.security.ssl.transport.truststore\_filepath LDAP authentication **URL:** \ **Category:** Security\ **Tags:** discuss, troubleshoot, configure\ **Created:** [March 7, 2023, 11:05am UTC](https://forum.opensearch.org/t/empty-file-path-for-plugins-security-ssl-transport-truststore-filepath-ldap-authentication/12991 "2023-03-07T11:05:47Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![vasmihay](https://avatars.discourse-cdn.com/v4/letter/v/ba8739/32.png) [@vasmihay](https://forum.opensearch.org/u/vasmihay)\ **Post date:** [March 7, 2023, 11:05am UTC](https://forum.opensearch.org/t/empty-file-path-for-plugins-security-ssl-transport-truststore-filepath-ldap-authentication/12991/1 "2023-03-07T11:05:48Z")
**Versions** (relevant - OpenSearch/Dashboard/Server OS/Browser): **OpenSearch** : ```auto "version" : { "number" : "7.10.2", "build_type" : "rpm", "build_hash" : "e505b10357c03ae8d26d675172402f2f2144ef0f", "build_date" : "2022-01-14T03:38:06.881862Z", "build_snapshot" : false, "lucene_version" : "8.10.1", "minimum_wire_compatibility_version" : "6.8.0", "minimum_index_compatibility_version" : "6.0.0-beta1" }, ``` **OS** : ```auto NAME="CentOS Stream" VERSION="8" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Stream 8" ``` **Describe the issue** : The thread is a continuation of the Git issue reported [here](https://github.com/opensearch-project/security/issues/1866). If the `security.ssl.transport.truststore_filepath` is missing from the `opensearch.yml` the LDAP authentication cannot be completed. **Configuration** : **opensearch.yml:** ```auto network.host: "0.0.0.0" node.name: "vasko-node-1" cluster.initial_master_nodes: - "vasko-node-1" cluster.name: "vasko-wazuh-cluster" node.max_local_storage_nodes: "1" path.data: "/var/lib/wazuh-indexer" path.logs: "/var/log/wazuh-indexer" plugins.security.ssl.http.pemcert_filepath: /etc/wazuh-indexer/certs/indexer.pem plugins.security.ssl.http.pemkey_filepath: /etc/wazuh-indexer/certs/indexer-key.pem plugins.security.ssl.http.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem plugins.security.ssl.transport.pemcert_filepath: /etc/wazuh-indexer/certs/indexer.pem plugins.security.ssl.transport.pemkey_filepath: /etc/wazuh-indexer/certs/indexer-key.pem plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem #plugins.security.ssl.transport.truststore_filepath: /etc/wazuh-indexer/certs/jks_cacerts plugins.security.ssl.http.enabled: true plugins.security.ssl.transport.enforce_hostname_verification: false plugins.security.ssl.transport.resolve_hostname: false plugins.security.authcz.admin_dn: - "CN=admin,OU=Wazuh,O=Wazuh,L=California,C=US" plugins.security.check_snapshot_restore_write_privileges: true plugins.security.enable_snapshot_restore_privilege: true plugins.security.nodes_dn: - "CN=vasko-node-1,OU=Wazuh,O=Wazuh,L=California,C=US" plugins.security.restapi.roles_enabled: - "all_access" - "security_rest_api_access" plugins.security.system_indices.enabled: true plugins.security.system_indices.indices: [".opendistro-alerting-config", ".opendistro-alerting-alert*", ".opendistro-anomaly-results*", ".opendistro-anomaly-detector*", ".opendistro-anomaly-checkpoints", ".opendistro-anomaly-detection-state", ".opendistro-reports-*", ".opendistro-notifications-*", ".opendistro-notebooks", ".opensearch-observability", ".opendistro-asynchronous-search-response*", ".replication-metadata-store"] ### Option to allow Filebeat-oss 7.10.2 to work ### compatibility.override_main_response_version: true ``` **config.yml** ```auto --- _meta: type: "config" config_version: 2 config: dynamic: http: anonymous_auth_enabled: false xff: enabled: false internalProxies: "192\\.168\\.0\\.10|192\\.168\\.0\\.11" authc: kerberos_auth_domain: http_enabled: false transport_enabled: false order: 6 http_authenticator: type: "kerberos" challenge: true config: krb_debug: false strip_realm_from_principal: true authentication_backend: type: "noop" basic_internal_auth_domain: description: "Authenticate via HTTP Basic against internal users database" http_enabled: true transport_enabled: true order: 4 http_authenticator: type: "basic" challenge: true authentication_backend: type: "intern" proxy_auth_domain: description: "Authenticate via proxy" http_enabled: false transport_enabled: false order: 3 http_authenticator: type: "proxy" challenge: false config: user_header: "x-proxy-user" roles_header: "x-proxy-roles" authentication_backend: type: "noop" jwt_auth_domain: description: "Authenticate via Json Web Token" http_enabled: false transport_enabled: false order: 0 http_authenticator: type: "jwt" challenge: false config: signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key" jwt_header: "Authorization" jwt_url_parameter: null roles_key: null subject_key: null authentication_backend: type: "noop" clientcert_auth_domain: description: "Authenticate via SSL client certificates" http_enabled: false transport_enabled: false order: 2 http_authenticator: type: "clientcert" config: username_attribute: "cn" challenge: false authentication_backend: type: "noop" ldap: description: "Authenticate via LDAP or Active Directory" http_enabled: true transport_enabled: true order: 5 http_authenticator: type: "basic" challenge: true authentication_backend: type: "ldap" config: enable_ssl: true enable_start_tls: false enable_ssl_client_auth: false **pemtrustedcas_filepath: /etc/wazuh-indexer/certs/tls-ca-bundle.pem** verify_hostnames: true hosts: - "prd-ds.pixelpark.com:636" bind_dn: "uid=test-wazuh,ou=wazuh,ou=Applications,o=Pixelpark,o=isp" password: "mysecurepass" userbase: "ou=People,o=Pixelpark,o=isp" usersearch: "(&(uid={0}))" username_attribute: "uid" authz: roles_from_myldap: description: "Authorize via LDAP or Active Directory" http_enabled: true transport_enabled: true authorization_backend: type: "ldap" config: enable_ssl: true enable_start_tls: false enable_ssl_client_auth: false verify_hostnames: true hosts: - "prd-ds.pixelpark.com:636" bind_dn: "uid=test-wazuh,ou=wazuh,ou=Applications,o=Pixelpark,o=isp" password: "mysecurepass" rolebase: "ou=Groups,o=Pixelpark,o=isp" rolesearch: "(uniqueMember={0})" userroleattribute: null userrolename: "memberOf" rolename: "cn" resolve_nested_roles: false userbase: "ou=People,o=Pixelpark,o=isp" usersearch: "(&(uid={0}))" username_attribute: "uid" skip_users: - admin - kibanaserver roles_from_another_ldap: description: "Authorize via another Active Directory" http_enabled: false transport_enabled: false authorization_backend: type: "ldap" ``` I tried to use the `pemtrustedcas_filepath` and also the `pemtrustedcas_content` as noted in the docs: > **[Active Directory and LDAP](https://opendistro.github.io/for-elasticsearch-docs/docs/security/configuration/ldap/#certificate-validation)** > > Documentation for Open Distro, the community-driven, 100% open source distribution of Elasticsearch OSS with advanced security, alerting, deep performance analysis, and more. Also tried to validate via TLS client authentication: **Relevant Logs or Screenshots** : ```auto [2023-03-07T11:20:38,061][WARN][c.a.d.a.l.b.LDAPAuthorizationBackend] [vasko-node-1] Unable to connect to ldapserver host.com:636 due to OpenSearchException[Empty file path for plugins.security.ssl.transport.truststore_filepath]. Try next. ``` **Working state** : If I add the `plugins.security.ssl.transport.truststore_filepath ` setting explicitly to the `opensearch.yml` the LDAP authentication starts to work as expected. According to the docs, the option is listed as optional, whereas for authorization it seems it is required: > **[Configuring TLS certificates](https://opensearch.org/docs/latest/security/configuration/tls/#keystore-and-truststore-files)** > > Configuring TLS certificates ---
**Author:** ![pablo](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/pablo/32/10363_2.png) [@pablo](https://forum.opensearch.org/u/pablo)\ **Post date:** [March 9, 2023, 1:16am UTC](https://forum.opensearch.org/t/empty-file-path-for-plugins-security-ssl-transport-truststore-filepath-ldap-authentication/12991/2 "2023-03-09T01:16:58Z")
@vasmihay I did some testing and got the same results. The LDAP authc and authz failed to work when `pemtrustedcas_filepath` in config.yml and `plugins.security.ssl.transport.truststore_filepath` in opensearch.yml where not configured. The documentation doesn’t refer to the `plugins.security.ssl.transport.truststore_filepath` option as it mentions below ones. ```auto plugins.security.ssl.transport.pemtrustedcas_filepath: ... plugins.security.ssl.http.truststore_filepath: ... ``` I’ve also checked early versions of ODFE up to version 1.13.x and this also was the case there. I think the documentation is/was incorrect and `plugins.security.ssl.transport.truststore_filepath` is required for LDAP and OIDC authentication. At this point, the only workaround is to either create a keystore with AD RootCA and use `plugins.security.ssl.transport.truststore_filepath`in opensearch.yml or add the cert using `pemtrustedcas_filepath` in config.yml In the mentioned bug there is a link to a piece of code that might be responsible for the logic of reading the IdP RootCA. It looks like the security plugin first checks the `pemtrustedcas_filepath` in config.yml and then `plugins.security.ssl.transport.truststore_filepath`in opensearch.yml > As per the recent comments in the GitHub bug, could you open a new Bug and ask to confirm if the documentation is incorrect and if the logic of searching the IdP RootCA certificate is as I described above? Please share the link to the new Bug here. ---
**Author:** ![vasmihay](https://avatars.discourse-cdn.com/v4/letter/v/ba8739/32.png) [@vasmihay](https://forum.opensearch.org/u/vasmihay)\ **Post date:** [March 13, 2023, 1:57pm UTC](https://forum.opensearch.org/t/empty-file-path-for-plugins-security-ssl-transport-truststore-filepath-ldap-authentication/12991/3 "2023-03-13T13:57:22Z")
Thank you for the investigation @pablo. I already added `plugins.security.ssl.transport.truststore_filepath` in the `opensearch.yml` and set the correct CA cert. As per your request, I submitted a new Github issue: > > > \*\*What is the bug?\*\* > This is a continuation of the issue \[1866\](https://github.…com/opensearch-project/security/issues/1866). The LDAP authentication process fails when the \`security.ssl.transport.truststore\_filepath\` is missing from the \`opensearch.yml\` file, leading to an unresolved bug from a previous issue. The steps to reproduce the bug are documented in the Opensearch forum thread, along with the host/environment details. > > \*\*How can one reproduce the bug?\*\* > Steps to reproduce the behavior: > > All the steps and config files are published in https://forum.opensearch.org/t/empty-file-path-for-plugins-security-ssl-transport-truststore-filepath-ldap-authentication/12991 thread. > > \*\*What is the expected behavior?\*\* > The LDAP authentication process should function as expected when the \`security.ssl.transport.truststore\_filepath\` is missing from the \`opensearch.yml\` file, and the \`pemtrustedcas\_filepath:\` is included in the \`config.yml\` file > > \*\*What is your host/environment?\*\* > All the information is provided in the Opesearch forum thread > > \*\*Do you have any screenshots?\*\* > If applicable, add screenshots to help explain your problem. > > \*\*Do you have any additional context?\*\* > It appears that the Java code responsible for the logic of how the CA certificates are read is located at \[this location\](https://github.com/opensearch-project/security/blob/main/src/main/java/com/amazon/dlic/util/SettingsBasedSSLConfigurator.java#L181). We are unsure if the documentation is incorrect, as the \`security.ssl.transport.truststore\_filepath\` option is listed as optional, while it appears to be required for authorization. We are also considering the possibility of changing the logic for searching the IdP RootCA certificate