Unable to use Linked (vault) X.509 Certificate Credentials

Hello

This might be related to a recent change fro a smartcard logon issue on some Windows systems. I've had a few reports of it causing problems. I'm still looking into that.

In the immediate term, to unblock you and help identify the issue, can you try this:

• Close RDM completely
• Locate the RemoteDesktopManager.cfg file (typically in %localappdata%\Devolutions\RemoteDesktopManager)
• Make a backup of that file before editing it
• Before the closing </Option> tag, add the line <DisableSmartCardKerbCertificateLogon>true</DisableSmartCardKerbCertificateLogon>
• Save the file and relaunch RDM

Do things work correctly again? This is valuable information because ti will show us that it's this fix causing an issue for you, and also give you a viable workaround for now.

Let me know if something isn't clear

I downgraded yesterday to be able to work for the day and today when I upgraded, it upgraded to 2026.2.17.0 64 bit. The issue I reported on the .16 version remained on the .17 version. I did not re-test the .16 version.

I tried what you suggested and found that adding the line did resolve the problem for me as I was able to RDP to computers successfully using the linked x.509 certificate. Thank you!

Can I provide you with any other information that could help you determine a long-term resolution?

Hello

Thanks for confirming the workaround.

If you don't mind entertaining some more troubleshooting from my side:

• Do you have the PIN stored in the X.509 credential? Or you were always entering it manually?
• Is this a vanilla RDP environment? Or are you using other third party software here? A good example would be Citrix.

Thanks and kind regards,

Hello

Thanks for confirming the workaround.

If you don't mind entertaining some more troubleshooting from my side:

• Do you have the PIN stored in the X.509 credential? Or you were always entering it manually?
• Is this a vanilla RDP environment? Or are you using other third party software here? A good example would be Citrix.

Thanks and kind regards,

@Richard Markiewicz
I have the pin stored. We are not using Citrix. We do have a smart card client installed on the devices (both the device initiating and device being RDP'd to). Some of the places I was trying to connect had the RDP port changed to something other than 3389 (it's been that way for years).

Hello

Thanks for the extra details.

First, here's some background for you. The way this works in RDM is: the embedded RDP control from Microsoft does not accept a smart card for authentication, only a username and password. However Microsoft provides another API for this scenario which serializes a certificate thumbprint in a special way and use it as a "username" (and the PIN is the "password"). The APIs on the other end are smart enough to recognize the serialized certificate thumbprint and use smart card authentication in place of username and password. That's all RDM does: call the Microsoft API to provide the certificate to the receiver, along with the PIN.

Unfortunately Windows has a regression since KB5066835, and we had to reverse engineer their libraries to see exactly what was going on. That update blocked access to the legacy crypto services APIs and now only allows access through the modern Windows APIs - again, this is all internal to Windows. The code path that is used on the Windows side when the client provides both the serialized smart card and the PIN has a bug; one function call is missing a flag needed to load the private key using the modern crypto backend.

(I call it a bug, maybe they're aware of it and it was intentional, maybe it will be fixed in the future; we have no idea).

Anyway, this broke the X.509 / RDP integration for a large portion of RDM users. So in 2026.2.14, after figuring out the above, we introduced a workaround where we hook certain function calls in the RDP library to allow this workflow to "work" again.

Unfortunately, yours is the second case we've seen where the workaround actually broke the integration. In the first case, I think it was related to Citrix; in your case I would guess it's related to whatever smart card middleware you're running on the client and/or server.

I doubt we'll be able to figure out the problem here, so the pragmatic thing (since the setting I showed you works for you) is to make this behaviour easier to opt-in to.

• Right now, you can manually set the option by hand-editing your .cfg file
• If you're in a domain environment and need to deploy this setting to several users, there's a group policy you can use - let me know if you want the details of that
• In an imminent update, I plan to raise this setting up to the UI so you can tweak it directly without editing the config manually or providing a policy

I am sorry for the inconvenience caused. Please let me know if you have any other questions or comments.

Kind regards,