The Okta Provisioning Agent uses certificates to establish secure communication between the agent and the SCIM server. Importing certificates into the Okta Provisioning Agent certificate trust store is required when a SCIM server fails to return a complete certificate chain or when using self-signed certificates. Resolve this by stopping the agent service, exporting the public certificate, and importing it into the Java keystore using the keytool command.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta Provisioning Agent
• On-Premises Provisioning (OPP)
• Windows Server
• Linux

How are certificates imported into the Okta Provisioning Agent on Linux?

Import certificates into the Okta Provisioning Agent on Linux by stopping the service, copying the exported public certificate to the server, and running the keytool command.

1. Stop the Okta Provisioning Agent service.
2. Export the public certificate from the certificate authority, SCIM server, or web browser.
3. Copy the certificate to the Linux server where the Okta Provisioning Agent is installed.
4. Run the following command as root or as a sudo user with admin privileges, replacing <Path to public certificate> with the actual file path:

/opt/OktaProvisioningAgent/jre/bin/keytool -import -file <Path to public certificate> -alias my_cert -keystore /opt/OktaProvisioningAgent/jre/jre/lib/security/cacerts

5. Enter the Java keystore password. NOTE: By default, this password is changeit.
6. Import additional certificates as desired, ensuring each certificate has a unique alias name (for example, my_cert1, my_cert2).
7. Restart the Okta Provisioning Agent service and test SCIM connectivity.

Import certificates into the Okta Provisioning Agent on Windows.

Import certificates into the Okta Provisioning Agent on Windows by stopping the service, copying the exported public certificate to the server, and executing the keytool command in the command prompt.

1. Stop the Okta Provisioning Agent service.
2. Export the public certificate from the certificate authority, SCIM server, or web browser.
3. Copy the certificate to the Windows server where the Okta Provisioning Agent is installed.
4. Run the following command as a user with admin privileges, replacing <Path to public certificate> with the actual file path:

"C:\Program Files\Okta\On-Premises Provisioning Agent\current\jre\bin\keytool.exe" -import -file <Path to public certificate> -alias my_cert -keystore "C:\Program Files\Okta\On-Premises Provisioning Agent\current\jre\lib\security\cacerts"

5. Enter the Java keystore password. NOTE: By default, this password is changeit.
6. Import additional certificates as desired, ensuring each certificate has a unique alias name (for example, my_cert1, my_cert2).
7. Restart the Okta Provisioning Agent service and test SCIM connectivity.

Review the Oracle documentation in the Related References section for complete documentation on the Java Runtime Environment (JRE) keytool program. Avoid using self-signed certificates in a production environment. While these steps remediate issues where the Okta Provisioning Agent fails due to a self-signed certificate, address the root cause and ensure that all production SCIM servers use signed certificates.

Related References

• Java keytool documentation