Monday, August 11, 2025

Oracle Forms “Failed to validate certificate” in UiPath RPA apps — why it happens and how to fix it

UiPath RPA workflow launches an Oracle Forms application (Java Web Start / Oracle Forms applet) and you intermittently get the pop‑up:

“Application Blocked for Security
Failed to validate certificate.
The application will not be executed.
Name: oracle.forms.engine.Main
Location: https://<server>:<port>”

you’re hitting a certificate revocation check problem in the Java client used by Oracle Forms. The issue appears randomly because Java’s Online Certificate Status Protocol (OCSP) checks can time out or fail intermittently against Oracle’s responders, which leads Java to treat the code-signing or TLS certificate as unvalidated and block execution.

Why this affects UiPath

  • UiPath typically automates Oracle Forms via a desktop/browser session that loads the Java plugin or JNLP client.

  • The robot inherits the same Java security settings as the user session. When OCSP validation is enabled, sporadic network hiccups or responder issues can fail the revocation check, stopping the Oracle client before your workflow starts.

  • Because the error occurs before the UI is fully initialized, retries don’t help; the Java runtime blocks the applet/JNLP outright.

Root cause in plain terms

  • Java tries to confirm that the certificate used to sign Oracle Forms code (and/or the site’s TLS certificate) hasn’t been revoked.

  • When “OCSP” is selected, Java queries an online OCSP responder. If that responder is slow, unreachable, or returns an unexpected response, Java refuses to run the application.

  • The result: intermittent “Failed to validate certificate” even when your certificates are valid.

The reliable fix: switch revocation checks to CRL only
Changing Java’s certificate revocation strategy from OCSP (or OCSP+CRL) to CRL only removes the flaky dependency on Oracle’s OCSP responders while still performing revocation checks via downloadable Certificate Revocation Lists.

What to change
Open the Java Control Panel on the robot and set the following under the Advanced tab, Security section.

  1. Check for signed code certificate revocation using:

  • Select “Certificate Revocation Lists (CRLs)”

  • Do not select OCSP or “Both CRLs and OCSP”

  1. Perform TLS certificate revocation checks on:

  • Choose “All certificates in the chain of trust” (recommended for completeness)

  • “Server certificate only” also works if your environment requires it

  • Avoid “Do not check”

  1. Check for TLS certificate revocation using:

  • Select “Certificate Revocation Lists (CRLs)”

  • Do not select OCSP or “Both CRLs and OCSP”

Apply and restart the browser/Oracle Forms client. In unattended robots, restart the robot session or machine so the setting is picked up.

Why CRL works better here

  • CRLs are cached and refreshed on schedule, so a transient network glitch doesn’t immediately block execution.

  • OCSP requires a live responder call during startup; if that call fails or times out, Java blocks the app. That’s the randomness you see.

Operational considerations for RPA teams

  • Standardize the Java security settings on all robots via group policy, configuration management, or golden image.

  • Ensure robots have access to CRL distribution points (often HTTP/LDAP URLs embedded in the certs). Allowlist those endpoints if you use egress filtering.

  • Monitor certificate expirations and keep Java up to date to avoid unrelated security prompts.

  • Document the setting so new robot machines match the same configuration.

FAQ

Does switching to CRL reduce security?

  • You still perform revocation checks, just via CRL instead of OCSP. Many enterprises standardize on CRL for determinism and caching. If your security policy mandates OCSP, consider deploying an internal OCSP responder or OCSP stapling; otherwise CRL is a practical, reliable choice.

Why does the error mention oracle.forms.engine.Main?

  • That’s the main class of the Oracle Forms client. Java blocks it before launch when it can’t validate certificates.

Why is the error intermittent?

  • OCSP lookups depend on remote responders. Latency, packet loss, DNS issues, or responder rate limits can cause sporadic failures.

UiPath workflow tip

  • Add an environment validation step at the start of your process that checks a sentinel Forms URL and fails fast with a clear exception if Java security settings are incorrect. This saves robot time and simplifies troubleshooting.

Summary

  • Symptom: “Failed to validate certificate” popup when launching Oracle Forms in a UiPath‑automated session.

  • Cause: Unreliable OCSP revocation checks in Java for Oracle Forms certificates.

  • Fix: In Java Control Panel > Advanced > Security, set revocation checks to CRL only for both signed code and TLS, then restart.

No comments: