End-to-end encryption verification fails when connecting through RustDesk OSS server

Environment

• RustDesk client version: 1.4.9 tested
• RustDesk server: OSS
• hbbs version: 1.1.15
• hbbr version: 1.1.15
• Server OS: Debian Linux
• Self-hosted ID and relay server
• Both clients are configured to use the same self-hosted server and the same current server public key.

Problem

When one RustDesk client attempts to connect to another client through the self-hosted OSS server, the following warning appears:

End-to-end encryption could not be verified.
The remote device may still be setting up. Please try again later.
If this continues, the server may not be trustworthy.
Continue anyway?

The original German message displayed by the client is:

Ende-zu-Ende-Verschlüsselung konnte nicht verifiziert werden.
Das entfernte Gerät wird möglicherweise noch eingerichtet. Versuchen Sie es später erneut.
Wenn dies weiterhin auftritt, ist der Server möglicherweise nicht vertrauenswürdig.
Trotzdem fortfahren?

Server-side observations

The hbbs log reports authentication failures such as:

Authentication failed from : for peer - invalid key

The server key was subsequently rotated, and both hbbs and hbbr report the same new public key.

Both clients were configured with the new public key.

Despite this, the end-to-end encryption verification warning may still appear when attempting to connect from one client to another.

Expected behavior

When:

• both clients use the same self-hosted ID server,
• both clients use the same relay server,
• both clients are configured with the correct current server public key,
• and hbbs and hbbr use the same key pair,

the clients should successfully verify the end-to-end encrypted connection without displaying a server trust warning.

Actual behavior

The client displays an end-to-end encryption verification warning and states that the server may not be trustworthy.

This occurs during an attempted connection between two RustDesk clients using the same self-hosted OSS infrastructure.

Important question

Is this behavior caused by:

• stale client-side key information after server key rotation,
• stale peer public-key information stored in db_v2.sqlite3,
• an incompatibility between RustDesk client 1.4.9 and OSS server 1.1.15,
• or a defect in peer key verification?

It would be helpful to know exactly how clients are expected to handle a server key rotation and whether existing peer public keys stored in the OSS server database must be cleared or re-registered after such a rotation.

Start by reproducing the connection with RustDesk client 1.4.9, OSS hbbs/hbbr 1.1.15, and the rotated server key while comparing hbbs authentication logs. Inspect how peer keys in db_v2.sqlite3 and client-side server keys are handled after rotation. Done means identifying whether the warning is expected, caused by stale keys or version incompatibility, or requires a focused fix and regression coverage.