UiPath Terminal Activities Connection Fails with "Unrecognized server certificate signature algorithm (RSASSA_PSS)" Error

News Knowledge Base
1

Why does UiPath Terminal Session activity fail to connect to an IBM AS/400 (iSeries) server after a new SSL certificate was installed on the server, and how to fix it?

Issue Description

After a server SSL certificate is renewed or replaced, automations using UiPath Terminal Activities to connect to IBM AS/400 / iSeries servers over SSL (typically port 992) may suddenly fail with the following errors:

Error seen in Orchestrator / Studio:

Terminal Session: One or more errors occurred.

(One or more errors occurred. (There was an error connecting to terminal. Error code: UnknownError | ResultCode=UnknownError| ConnectionStatus=Disconnected))

A more descriptive error can be found in Windows Event Viewer on the impacted Robot machine:

UiPathTerminal error 275 raised.

Error message: Unrecognized server certificate signature algorithm (RSASSA_PSS).

{"module":"telnet","function":"connecting"}

Why Does This Happen?

When a server renews its SSL certificate, the new certificate may be generated using the RSASSA-PSS signature algorithm (also referred to as PKCS #1 v2.1). While RSASSA-PSS is a valid and slightly more secure signing format, it is not widely supported across all platforms and software libraries.

UiPath's Terminal Activity library uses a lower-level TLS implementation that does not support the RSASSA-PSS signature algorithm. When the server presents a certificate signed with RSASSA-PSS, the Terminal Activity immediately rejects it and fails the connection.

This is different from how interactive terminal emulators (such as IBM iAccess / 5250 Emulator) behave those display an interactive pop-up asking the user to trust the certificate and can proceed after manual acceptance. UiPath Terminal Activities operate in headless/non-interactive mode and have no mechanism to handle this prompt, causing the session to fail silently.

How to Confirm This is Your Issue?

All of the following will be true:

  • Automation using Terminal Session activity was working before a server certificate was renewed
  • Automation started failing the day after the new certificate was installed
  • IBM iAccess / 5250 Emulator can still connect to the same server (possibly after clicking "Yes" on a certificate trust pop-up)
  • Windows Event Viewer on the Robot machine shows the RSASSA_PSS error message
  • The server certificate's Signature Algorithm shows rsassaPss when inspected

Additional Causes That May Accompany This Issue

When a server certificate is renewed, it is common for the following to also change:

  1. The Certificate Authority (CA) may have changed - the new certificate may be issued by a different internal CA than the previous one. The Robot machine will not automatically trust the new CA and it must be manually imported.
  2. The signature algorithm changed to RSASSA-PSS - the new certificate uses a signing format that UiPath's Terminal library cannot process.

Both issues must be addressed for the connection to succeed.

Resolution

There are two parts to the fix, handled by different teams. Both are required.

Part 1 — Import the New CA Certificate on the Robot Machine

(Windows Admin Team)

If the server's CA certificate changed when the server cert was renewed, the Robot machine will not trust the new CA. The new CA certificate must be imported into the Windows Trusted Root Certificate Authorities store on every Robot machine affected.

Step 1 - Obtain the CA certificate file

The CA certificate can be obtained from:

  • A machine where IBM iAccess already accepted the new certificate (it will be stored in that machine's certificate store)
  • Directly from the server/infrastructure team as a .cer or .crt file

To export from a machine where iAccess accepted it:

  1. Press Windows + R → type: certlm.msc → Enter
  2. Navigate to: Trusted Root Certification Authorities → Certificates
  3. Locate the new CA certificate (check Issued To / Issued By columns)
  4. Right-click → All Tasks → Export
  5. Select: DER encoded binary X.509 (.CER)
  6. Save and copy the file to the Robot machine

Step 2 - Import the CA certificate on the Robot machine

  1. Press Windows + R → type: certlm.msc → Enter (Accept the admin permission prompt)
  2. Right-click Trusted Root Certification Authorities → All Tasks → Import
  3. Browse to the CA certificate file
  4. Ensure destination store shows: Trusted Root Certification Authorities
  5. Click Next → Finish
  6. Confirm: "The import was successful"

Step 3 - Restart the UiPath Robot service

  1. Press Windows + R → type: services.msc → Enter
  2. Find UiPath Robot in the list
  3. Right-click → Restart
  4. Wait until Status shows Running

Part 2 — Reissue the Server Certificate Without RSASSA-PSS

(AS/400 / Infrastructure Team)

The server certificate must be reissued using the standard SHA-256 RSA signature algorithm instead of RSASSA-PSS. This is done through IBM Digital Certificate Manager (DCM) on the AS/400 server.

Step 1 - Open Digital Certificate Manager

In a browser, navigate to:

http://<AS400-hostname>:2001/QIBM/ICSS/cert/admin/qycucm1.ndm/main0

Log in with AS/400 admin credentials

Step 2 - Reissue the server certificate

  1. Select: Manage Certificates → Renew Certificate
  2. Locate the server certificate for the affected hostname
  3. When prompted for Signature Algorithm, select:
    SHA-256 with RSA
    Do NOT select RSASSA-PSS
  4. Keep all other settings the same:
    • Common Name (CN)
    • Subject Alternative Names (SANs)
    • Key size (RSA 2048-bit recommended)
  5. Complete the certificate generation

Step 3 - Restart AS/400 SSL services

Run the following commands on the AS/400:

ENDTCPSVR SERVER(*SSL)

STRTCPSVR SERVER(*SSL)

Step 4 - Re-test the automation

Re-run the affected UiPath automation. The Terminal Session should now connect successfully.

Interim Workaround — Switch to HLLAPI Mode

(If the server certificate cannot be reissued immediately)

If the infrastructure team cannot reissue the certificate right away, the automation can be temporarily unblocked by switching the Terminal Session from Direct connection to HLLAPI mode. In this mode, UiPath piggybacks on top of IBM iAccess (which handles SSL itself) instead of connecting directly to the server.

Pre-conditions:

  • IBM iAccess / 5250 Emulator must be installed on the Robot machine
  • IBM iAccess must be able to connect to the server successfully
  • Note the session letter in use (e.g. "A")

In UiPath Studio:

  1. Open the Terminal Session activity properties
  2. Change Connection Type from Direct to EHLLAPI
  3. Set Session letter to match the iAccess session (e.g. A)
  4. Save and republish the automation

Important: IBM iAccess must be open and connected on the Robot machine before the bot runs. For unattended robots, an additional step may be needed at the start of the workflow to launch iAccess automatically.