Articles in this section

Plesk migration in Windows fails: certificate verify failed: EE certificate key too weak

Applicable to:

  • Plesk for Windows

Symptoms

  • A migration from an older Plesk for Windows server (for example, Windows Server 2008 R2 to a newer target for example, Windows Server 2025) cannot be started. Plesk Migrator either runs endlessly at the connection stage or fails with:

    PLESK_ERROR: Panel Migrator failed to connect to RPC Agent running on '203.0.113.2' server.
    RPC Agent is required for communication between current server and '203.0.113.2' server

    1. Check that there are no firewall rules blocking connections to 10155 port on 203.0.113.2 from that server.
    Make sure you could connect to the source server by 10155 port with "telnet" utility running on that server.
    2. Check that agent is running on the source server (panel-migrator-rpc-agent.exe process)
    and listening on 10155 port. If it does not, try to start 'panel-migrator-rpc-agent.exe',
    which is usually installed to "%SYSTEMDRIVE%\plesk_migrator\rpc-agent\". If it is still not running -
    investigate debug.log and info.log files on 203.0.113.2 server
    (which are usually located at "%SYSTEMDRIVE%\plesk_migrator\rpc-agent\ directory).
    3. Try to upload RPC Agent installation package to the 203.0.113.2 server and run it manually.

    More details: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1007)

  • TCP port 10155 is reachable from the target to the source, and the panel-migrator-rpc-agent.exe process is running on the source. Only the TLS handshake fails.
  • The certificates used by Plesk Migrator for the RPC Agent have 1024-bit RSA keys:

PS openssl x509 -in "C:\Program Files (x86)\Plesk\var\modules\panel-migrator\rpc-agent\certificates\source-node.crt" -noout -text | findstr "Public-Key"
Public-Key: (1024 bit)

PS openssl x509 -in "C:\Program Files (x86)\Plesk\var\modules\panel-migrator\rpc-agent\certificates\migration-node.crt" -noout -text | findstr "Public-Key"
Public-Key: (1024 bit)

  • The certificate files are noticeably smaller than in a normal environment (898/936 bytes instead of 1274/1732 bytes) and carry an old creation date:

    PLESK_INFO: Directory: C:\Program Files (x86)\Plesk\var\modules\panel-migrator\rpc-agent\certificates

    Mode                LastWriteTime         Length Name
    -a----        6/29/2023   8:57 AM           898 migration-node.crt
    -a----        6/29/2023   8:57 AM           936 migration-node.key
    -a----        6/29/2023   8:57 AM           898 source-node.crt
    -a----        6/29/2023   8:57 AM           932 source-node.key
    -a----        6/29/2023   8:57 AM           158 ssl-keys-generated

Cause

The RPC Agent channel between the Plesk Migrator on the target server and the source server uses mutual TLS with certificates that Plesk Migrator generates for itself. These are stored in %plesk_dir%var\modules\panel-migrator\rpc-agent\certificates on the target and are also embedded in the RPC Agent package deployed to the source.

Plesk Migrator generated 1024-bit RSA keys in the past. Current versions generate 2048-bit keys, but the generator only creates a new pair when the certificate files are absent, so an existing weak pair is reused indefinitely.

The verification is performed by the OpenSSL library linked into the Python interpreter shipped with the RPC Agent. OpenSSL 1.1.1 and later, including OpenSSL 3.x, reject RSA keys smaller than 2048 bits at the default security level (SECLEVEL=1). The handshake therefore fails with EE certificate key too weak, regardless of the Schannel cipher and protocol configuration on either server.

This behavior is tracked under the bug report with ID #PMT-5695. Once a fix is available, it will be published in the Plesk changelog.

Resolution

Note: If you do not have administrative access to Plesk via RDP, contact your hosting provider regarding the issue.

Regenerate the Plesk Migrator certificate set on the target server and redeploy the RPC Agent on the source so both sides use the same new 2048-bit pair. Regenerating the certificates alone is not sufficient, because the agent package already deployed to the source still contains the old certificate material.

  1. Complete or cancel any migrations that are in progress on the target server. Migration data is lost when the extension is removed.
  2. Connect to the target server via RDP.
  3. Make a backup copy of the certificate directory, then rename or delete the original:

    C:\Program Files (x86)\Plesk\var\modules\panel-migrator\rpc-agent\certificates

  4. Reinstall the Plesk Migrator extension so the certificate pair is regenerated at 2048 bits.
  5. Confirm the new key size:

    PS openssl x509 -in "C:\Program Files (x86)\Plesk\var\modules\panel-migrator\rpc-agent\certificates\source-node.crt" -noout -text | findstr "Public-Key"
    Public-Key: (2048 bit)

  6. Connect to the source server and remove the previously deployed RPC Agent content from %SYSTEMDRIVE%\plesk_migrator\rpc-agent\.
  7. Deploy and start the new RPC Agent on the source server following Migration in Plesk cannot be started: Panel Migrator failed to install RPC Agent.
  8. Start the migration again.

Alternative: migrate using backup and restore

If the RPC Agent connection still cannot be established, for example because the RPC Agent package does not start on the legacy source operating system, use Plesk backup and restore as the migration path instead. This avoids the RPC Agent connection entirely:

  1. Create the required backups on the source server.
  2. Transfer the backup files to the target server.
  3. Restore them on the target server.

See Backing Up and Restoration for details.

Was this article helpful?

Comments

0 comments

Please sign in to leave a comment.