DPA – Login failed: Error occurred while authenticating AD/LDAP user (PKIX path building failed)

4/22/2026 4:46 PM

4/22/2026 4:46 PM

Symptoms

UI error

Login failed: Error occurred while authenticating AD/LDAP user (SunCertPathBuilderException)

or

Login failed: Error occurred while authenticating AD/LDAP user (PKIX path building failed: unable to find valid certification path to requested target)

Logs (for example, auth.log / idc.log)

org.springframework.security.authentication.InternalAuthenticationServiceException: dc01.example.local:3269
...
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
    unable to find valid certification path to requested target

OpenSSL test from DPA server

openssl s_client -connect dc01.example.local:3269 -showcerts

Output shows a certificate chain (server + intermediate CA) and:

Verify return code: 20 (unable to get local issuer certificate)

indicating the root of the chain is not trusted.

Database Performance Analyzer

DPA establishes LDAPS connections using Java’s SSL/TLS stack. During the SSL handshake, Java validates the certificate chain presented by the domain controller:

1. Server (leaf) certificate for dc01.example.local.

2. One or more intermediate CA certificates.

3. One or more root CA certificates.

If DPA’s effective truststores do not contain the intermediate and/or root CA certificates that issued the domain controller’s server certificate, Java cannot build a complete trust path and fails the handshake with:

PKIX path building failed: unable to find valid certification path to requested target

In DPA, trust is built from a merge of:

• The DPA truststore (by default:
  <DPA_HOME>\iwc\tomcat\ignite_config\security\dpa-truststore.jks)

• The Java truststore (by default:
  <DPA_HOME>\iwc\jre\lib\security\cacerts, unless overridden)

When your internal CAs are missing from these, all LDAPS operations (including AD/LDAP binds and AD domain validation in the wizard) can fail with the PKIX error even if credentials and LDAP settings are correct.

1. Confirm DPA truststore configuration

1. On the DPA server, open:

   <DPA_HOME>\iwc\tomcat\ignite_config\idc\system.properties
   

2. Locate the DPA truststore settings:

   com.confio.security.trustStore=../security/dpa-truststore.jks
   com.confio.security.trustStoreType=jks
   com.confio.security.trustStorePassword=<password>
   com.confio.security.trustStoreEnabled=true
   

   Ensure:

   • com.confio.security.trustStoreEnabled is true.

   • The path resolves to:

     <DPA_HOME>\iwc\tomcat\ignite_config\security\dpa-truststore.jks
     

3. Check whether Java truststore overrides are configured:

   javax.net.ssl.trustStore=<optional-custom-path>
   javax.net.ssl.trustStoreType=jks
   javax.net.ssl.trustStorePassword=<password>
   

   • If these are not set, Java uses:

     <DPA_HOME>\iwc\jre\lib\security\cacerts
     

In most deployments, importing the internal CA certificates into dpa-truststore.jks is sufficient. If javax.net.ssl.trustStore points to a different keystore, that keystore must also trust the same CA chain.

---

2. Export the LDAPS certificate chain from a domain controller

From the DPA server, run:

openssl s_client -connect dc01.example.local:3269 -showcerts

(Replace dc01.example.local and 3269 with the actual FQDN and LDAPS port the customer configured in DPA.)

From the output, identify:

• Server certificate (leaf) – s=CN=dc01.example.local

• Intermediate CA certificate(s) – for example s=CN=Internal Issuing CA 01, DC=example, DC=local

• Root CA certificate(s) – often not included in this output and must be obtained from the customer’s PKI team or CA portal.

Save the certificate blocks (-----BEGIN CERTIFICATE----- … -----END CERTIFICATE-----) as:

• dc01_server.cer (optional)

• internal_issuing_ca_01.cer

• internal_root_ca.cer (from CA export if not in the OpenSSL output)

---

3. Import CA certificates into the DPA truststore

Use the keytool utility from the JRE shipped with DPA.

1. On the DPA server, open an elevated command prompt.

2. Change to the DPA JRE bin directory:

   cd /d "<DPA_HOME>\iwc\jre\bin"
   

3. Import the intermediate CA:

   keytool -importcert ^
     -alias internal-issuing-ca-01 ^
     -file "C:\path\to\internal_issuing_ca_01.cer" ^
     -keystore "<DPA_HOME>\iwc\tomcat\ignite_config\security\dpa-truststore.jks"
   

4. Import the root CA:

   keytool -importcert ^
     -alias internal-root-ca ^
     -file "C:\path\to\internal_root_ca.cer" ^
     -keystore "<DPA_HOME>\iwc\tomcat\ignite_config\security\dpa-truststore.jks"
   

5. When prompted, enter the password specified in:

   com.confio.security.trustStorePassword=...
   

6. (Optional) Verify the contents:

   keytool -list -keystore "<DPA_HOME>\iwc\tomcat\ignite_config\security\dpa-truststore.jks"
   

   Confirm entries for internal-issuing-ca-01 and internal-root-ca exist.

If javax.net.ssl.trustStore is configured to a custom keystore, repeat the import steps for that keystore as well.

---

4. Restart the DPA service

Restart DPA so it reloads the merged truststore:

• Windows (service name may be “Ignite PI Server” or similar):

  sc stop "Ignite PI Server"
  sc start "Ignite PI Server"
  

• Linux (example):

  <DPA_HOME>/iwc/tomcat/bin/shutdown.sh
  <DPA_HOME>/iwc/tomcat/bin/startup.sh
  # or, if a systemd unit exists:
  # sudo systemctl restart dpa
  

---

5. Re‑test AD/LDAP and verify logins

1. Log into the DPA web console with either:

   • A local DPA user (for example, the repository owner account defined in repo.properties), or

   • An AD/LDAP user if login already works.

2. Navigate to Options → Active Directory / LDAP.

3. Use the Test / Validate function for the configured domain.

Expected results:

• No Certificate of the LDAP server is not trusted or PKIX path building failed messages.

• AD/LDAP validation completes successfully.

• AD/LDAP users can log in through the DPA web console without the PKIX error.

If issues remain, re‑check:

• The LDAPS hostname in DPA matches a CN or SAN on the server certificate.

• The entire certificate chain (intermediate + root CA) is present in at least one of the effective truststores.

• There are no additional errors in auth.log / idc.log (for example, invalid bind credentials).

---

Temporary workaround – Disable AD/LDAP and use local login

If SSL trust cannot be fixed immediately and DPA access is blocked, AD/LDAP can be temporarily disabled so a local admin can log in.

1. Identify the repository owner (local DPA admin)

Check:

<DPA_HOME>\iwc\tomcat\ignite_config\idc\repo.properties

Look for:

repo.user=<DOMAIN>\\<username>

This user is the DPA Repository Owner and has admin privileges in the DPA web console. If needed, reset this password following the standard DPA repository owner password reset procedure.

2. Disable LDAP in system.properties

Edit:

<DPA_HOME>\iwc\tomcat\ignite_config\idc\system.properties

Comment out or remove LDAP configuration lines, for example:

#com.confio.security.ldap.enabled=true
#com.confio.security.ldap.serverUrl1=ldaps://dc01.example.local:3269
#com.confio.security.ldap.serverUrl2=ldaps://dc02.example.local:3269
#com.confio.security.ldap.isActiveDirectory=true
#com.confio.security.ldap.baseDn=DC=example,DC=local

Save the file and restart DPA.

3. Log in with local admin

Use the repository owner account (from repo.user) and its password to log in. After fixing the truststore and certificates, AD/LDAP can be re‑enabled and validated via Options → Active Directory / LDAP.

---

Additional information and best practices

• Use the DPA truststore for customer CAs:
  Prefer importing customer internal CA certificates into dpa-truststore.jks rather than editing Java’s global cacerts. This improves resilience across JRE and DPA upgrades.

• Keep hostnames consistent:
  Ensure the LDAPS hostname configured in DPA (ldaps://dc01.example.local:3269) matches a CN or SAN entry on the server certificate.

• Validate certificate chain regularly:
  Use openssl s_client -connect <dc-fqdn>:<port> -showcerts from the DPA server to confirm what certificate chain the domain controller presents and to quickly see if the chain is trusted.

• Apply to all DCs used by DPA:
  If DPA is configured with multiple domain controllers, verify they use a consistent PKI chain or ensure all required intermediate and root certificates are present in the truststores.