Troubleshoot the Delinea Credential Resolver

This topic covers common issues with the Delinea Credential Resolver for MID Server and provides steps to identify and resolve them.

Decryption / Parameter Issue (Config Mismatch)

A configuration mismatch occurs when the credential resolver version and the Setup Utility version are out of sync, resulting in incorrect parameter names in config.xml.

Symptoms

One or more of the following messages appear in wrapper.log:

  • Failed to decrypt the ss_auth_str or platform_auth_str string

  • Unable to parse the param from config.xml file

  • Unable to read data from config.xml file of MID Server

  • Please check the Secret Server url and credential in config.xml file

Root Cause

The credential resolver is version 5.0 or above, but an older Setup Utility JAR was used to generate config.xml. Parameter names changed in version 5.0:

  • Added parameters: ss_url, platform_url, platform_auth_str, ss_auth_str

  • Removed parameters: ss_or_platform_url, ss_or_platform_auth_str

Solution

  1. Navigate to MID_Server\agent\extlib and verify that the credential resolver JAR files are version 5.0 or above.

  2. Run the correct Setup Utility for the installed resolver version:

    • DelineaMidServerCLIUtility-5.2.0.jar, or

    • DelineaMidServerUIUtility-5.2.0.jar

  3. Regenerate the parameters in config.xml.

  4. Restart the MID Server service.

  5. Test the connection again in ServiceNow.

PKIX Path Building Failed (Certificate Issue)

This issue occurs when the MID Server does not trust the SSL certificate presented by the Delinea Secret Server or Platform.

Background: How SSL Trust Works

The MID Server (and the credential resolver JAR) relies on the Java truststore (cacerts) to validate the HTTPS certificate presented by the Delinea Secret Server. During initial setup, there is typically no need to manually import certificates, as long as the certificate chain presented by the server is trusted by the default Java truststore.

If the Secret Server is updated to use a certificate chain that includes a new intermediate certificate not present in the MID Server's Java truststore, SSL validation fails.

There are no automatic updates to the MID Server truststore. Any new or missing intermediate certificates must be added manually.

Certificate Chain Rotation

If the integration was working previously and starts failing, the cause is typically a certificate expiration or a change in the certificate chain. For example, Sectigo intermediate certificates rotated in April 2025 may cause trust failures if the new intermediate is not present in the MID Server's truststore.

If everything was working previously, it typically indicates that:

  • The truststore already contained the required root and intermediate certificates, or

  • The server was presenting a certificate chain compatible with the existing truststore.

In such cases, the new intermediate certificate must be imported into the MID Server's Java truststore to reestablish trust.

Diagnostic Checklist

Before proceeding with the solution steps, administrators should confirm the following:

  • Whether the SSL certificate or certificate chain was recently updated on the Secret Server.

  • The exact error message observed (for example, PKIX or certificate path errors) to validate that this is a trust-related issue.

Error

The following message appears in wrapper.log:

PKIX path building failed: SunCertPathBuilderException: unable to find valid certification path

Root Cause

The MID Server's Java truststore does not contain the root or intermediate certificate required to trust the SSL certificate from the Delinea Secret Server or Platform.

Solution

  1. Export the SSL certificate from a browser:

    1. Navigate to the Secret Server URL in a browser.

    2. Click the site icon in the address bar.

    3. Select Certificate > Details > Export and save the certificate in DER-encoded binary (.cer) format.

  2. Open a terminal and navigate to the Java bin directory:

    MID_Server\agent\jre\bin

  3. Run the following command, replacing the alias name and file path with the appropriate values for the environment:

    keytool -import -alias certificateAliasName -file "path\to\example.cer" -keystore "MID_Server\agent\jre\lib\security\cacerts"

    • -alias — A meaningful name for the certificate alias.

    • -file — The path of the exported .cer certificate.

  4. When prompted, enter the keystore password. The default password is changeit.

  5. When prompted to trust the certificate, select Yes. The certificate is imported into the truststore.

  6. (Optional) Verify the import by listing all certificates in the truststore:

    keytool -list -keystore "MID_Server\agent\jre\lib\security\cacerts"

  7. Restart the MID Server service.

For additional details, see Adding an SSL Certificate to a MID Server.

Authentication Failed During Test Connection

If a test connection fails with an authentication error, use the following steps to isolate the cause.

Validate the Credential Without the Resolver

  1. Test the same credential directly in ServiceNow without the Delinea Credential Resolver.

  2. If the test fails, the issue is with the credential itself, not the resolver. Verify the credential is correct before proceeding.

  3. If the test succeeds, continue with the steps below.

Verify Secret Field Mapping

Confirm that the field values in the ServiceNow credential record match the corresponding fields in the Delinea secret exactly. Any mismatch between field names or values can cause authentication failures.

Check the Template Type

Custom secret templates can cause issues if the slug name does not match the resolver's field mapping file (ss-credential-resolver-field-mappings.json). Where possible, use a built-in template such as AD Account to avoid mapping issues.

Check Token and Grant File Mode

If the resolver uses Grant File mode:

  • The token may be expired. Check wrapper.log for token-related errors.

Verify Permissions

Confirm that the application or service account used by the resolver:

  • Has access to the target secret.

  • Has the required View and Retrieve permissions on the secret.

Check Logs and Configuration

Review the following files for additional error details:

  • config.xml

  • wrapper.log

Check Network Connectivity

Confirm that the MID Server can reach the target machine. Ping the target to verify basic network connectivity.