Troubleshooting

To collect logs for ServiceNow Mid Server instances, follow these steps:

  1. Check the Logs file of MID Server in case of failures. Logs are stored at <Mid Server installation path> / agent/log/.

  2. Select the wrapper.log file to be shared.

    Ensure the log level is configured to 4 to capture detailed logs, especially when validating credentials.

  3. Review the wrapper.log file for any debug messages or errors related to the issue.

Known Issues

Credential Resolver Configuration – Secret Name Encoding

When using a Secret Name as the ServiceNow Credential ID, ensure the name is properly URL encoded. Secret names containing spaces or special characters must be encoded (e.g., My%20Secret instead of My Secret).

Alternatively, set the parameter search_secret_by_name=false and use the Secret ID instead. This avoids issues with URL encoding.

Active Directory Account – Domain Requirement

The credential resolver does not automatically retrieve the Domain field from the Active Directory Account template.

To ensure successful authentication, add the domain as a prefix to the Username field in the secret (e.g., DOMAIN\username).

Active Directory Secret Creation Template Issue

When creating a secret for an Active Directory account, always select the Windows Account template. Ensure that you enter the username in the correct format: domain\username.

This format works for both ServiceNow and Secret Server.

If the AD template is specifically required, ensure the Delinea Credential Resolver is configured so the username includes the domain; otherwise, ServiceNow validation may succeed, but Secret Server RPC/heartbeat will fail.

*Delinea includes both default templates (e.g., Windows, MySQL, SSH) and custom templates for specialized use cases). To learn more about secret templates, go here Built-in Secret Templates.

Certificate Errors

If you see failures in validating credentials, review the MID Server's agent log. If you find errors referring to PKIX path failures, the SSL certificate for Secret Server needs to be imported into the Java Keystore for the MID Server agent, see the Adding SSL Certificate to MidServer for more details.

PKIX Errors Example Log:

alt

If the Credential Resolver is not working, use the following solutions.

  • External Credential storage ServiceNow instance plugin: After adding External Credential storage plugins to ServiceNow instance, sometimes user can't see the checkbox for External Credential Store plugin on credentials page (ServiceNow instance > Discovery > Credentials). To solve this problem, wait and refresh at regular intervals.

  • Authentication fails: Check the following if authentication fails.

    • Correct the credentials of a Secret in Secret Server.
    • The user in configuration file should have a View permission under Secret > Sharing in Secret Server.
    • Check the permissions of the Secret Server user that was used in the configuration file. The user should have an Application Account with at least View Launcher Password permission.

    • Check the Secret Server ss_url , ss_auth_str parameters in the config.xml file.

    • Verify the credentials you entered when running the DelineaMidServerUIUtility-5.2.0.jar file.

  • Timeout Exception: If network issues occur, a user might experience a timeout exception. If this happens, check the network and restart the MID Server and validate it again.

  • Invalid target specified: During the test if the user receives an invalid target specified message, do the following:

    • Check the hostname or the IP address of a Secret in Secret Server.
    • Use the IP address entered while testing the credential. Make sure it is correct and the machine credential is in the Secret Server template.

  • Version Mismatch: If the user has a version mismatch, upgrade MID Server because the ServiceNow instance was upgraded to a higher version.

  • Unable to decrypt the credential: The encrypted string copied from the command prompt to config.xml failed to decrypt.

    • Run the DelineaMidServerUIUtility-5.2.0.jar file on the same server as the Mid Server.

    • Ensure tags are copied correctly.

  • Unable to run the DelineaMidServerSetupUtility JAR file:

    Use "Java -version" command to ensure that Java 11 or higher is installed on your machine.

  •  Debugging Tips:
    • If the plugin is not working, check the MID Server Logs file. Check to see that all configurations of config.xml file are correct.
    • Check the user permission in Secret Server for the user which is configured in MID Server config.xml file (MID Server path/agent/config.xml).
    • Check all the Secret details in the Secret, (for example, passwords and machine details).

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.