Gateway versuib 2926.2.2.0 not working

Hello,
Thank you for reaching to our forum, both errors are related and have a known root cause: your gateway.json contains a WebApp section that the DVLS Console can no longer parse correctly after the upgrade, which triggers that unhandled exception when you click Edit on the Gateway. That same broken config state is also what is causing the "Gateway ID Unknown" error when RDM tries to open a session through it.
The fix is straightforward:

1. Stop the Devolutions Gateway service on the Gateway host (open Services.msc, find "Devolutions Gateway", stop it).
2. Open C:\ProgramData\Devolutions\Gateway\gateway.json in a text editor.
3. Find the "WebApp" block and delete it entirely, along with the comma that immediately precedes the opening brace of that section.
4. Save the file, then start the Devolutions Gateway service again.
5. In DVLS Console, try editing the Gateway settings again. The exception should be gone.
6. In the DVLS web interface, go to Administration > Devolutions Gateway and confirm the Gateway shows as Online.
7. Try opening a session from RDM.

If the "Gateway ID Unknown" error in RDM persists after all of that, please reply with the DVLS and Gateway versions you upgraded from and to, and we can look at whether a re-pairing step is needed.

Best regards,

Hi Michel,

Removing the WebApp section solved the problem with editing the settings but we still get the Gateway ID error.

We upgraded from these versions:

DVLS: 2026.1.16.0 => 2026.2.5.0
Gateway: 2026.1.0 => 2026.2.2
RDM: 2026.1.10.0 => 2026.2.8.0

I also got the Gateway ID error before updating the gateway to 2026.2.2 after I updated DVLS.

Today I upgraded to DVLS version 2026.2.7.0 and still the same problem.

Please let me know what the next steps are to fix this problem.

Hi hjbos,
Thanks for the follow-up, and good to hear the WebApp change cleared the Console error.
For the Gateway ID error, let's confirm the ID first, since that error usually means the ID the server has for the Gateway and the one in the Gateway's own config no longer line up. Could you do the following:

1. In the DVLS web interface, go to Administration > Devolutions Gateway, open the Gateway entry, and note the Gateway ID shown there.
2. On the Gateway host, open gateway.json and compare the Id value against what DVLS shows. They should match exactly.
3. From the same Administration > Devolutions Gateway screen, use the ellipsis (More) menu and select Publish revocation list to all gateways. If a Publish Gateway configuration option is offered, run that one first, then the revocation list.

If the IDs do not match, or step 3 doesn't clear it, the cleanest fix is to remove the Gateway from the list in the web interface and add it back, then ping it to confirm it shows online. These two pages walk through the Add flow and the publish steps if you want a reference:
https://docs.devolutions.net/server/web-interface/administration/modules/gateway/
https://docs.devolutions.net/gateway/getting-started/devolutions-server/devolutions-gateway-configuration-with-devolutions-server/
If the error still persists after re-adding, let me know and we can open a support case to collect your server logs and gateway.json, or jump on a short session if it isn't clear from the logs.
Best regards,

Hi Michel,

De Id was the same, after publish revocation list still the same problem. After I removed the gateway from the web interface and I tried to add the gateway I get the following error:


Pressing continue and save did not work, I get a more detailed error:

Hi hjbos,
Thanks for the update and the two screenshots. They point straight to the cause, which is the certificate. When you re-add the Gateway, the server cannot validate the Gateway's TLS certificate, so the dialog comes up empty and the save fails. That same failure is why the Gateway ID still reads as unknown, since a Gateway the server cannot verify is treated as unreachable. The error on "Continue and save" is a separate display issue on our side that I am flagging internally. The certificate is the breaking point, so the goal is to get the Gateway serving a valid certificate on its own before configuring it in Devolutions Server again.
On the Gateway machine, please confirm the certificate matches what the Gateway configuration requires:

1. The Gateway is configured with its fully qualified domain name as its hostname, and that same FQDN is the URL used everywhere.
2. The certificate is a full chain certificate that includes the intermediate and root certificates.
3. The certificate's SAN matches that FQDN exactly, and the CN should match it as well.
4. The private key is present, and the account the Devolutions Gateway service runs under has read permission on it.
5. The Devolutions Gateway service is running.

The quickest way to confirm all of this at once is to request https://your-gateway-fqdn:7171/jet/health from the Devolutions Server machine and check that you get a health response and that the certificate it serves shows the full chain and the correct FQDN. If that request fails or the certificate is not right, the problem is on the Gateway and needs to be corrected there first. Once that endpoint responds cleanly with a valid certificate, adding the Gateway in Devolutions Server will go through without the certificate prompt, and the Gateway should come back online and clear the ID error. If it is easier, I can open a support case to go through the gateway.json, the certificate, and the logs with you directly.
Best regards,
Michel

For what it's worth, I get the exact same error message and the health page looks fine and secured with https.

TypeError: Cannot read properties of null (reading 'thumbprint')
at Object.acceptFunction (https://test.internal.local/dvls/chunk-UIUVVVBZ.js:89:158555)
at Object.accept (https://test.internal.local/dvls/chunk-4F5ISJSR.js:1:3289)
at r.finalize (https://test.internal.local/dvls/chunk-EWMDJ2PR.js:4654:1260)
at Object.accept [as next] (https://test.internal.local/dvls/chunk-EWMDJ2PR.js:4654:981)
at Qs.next (https://test.internal.local/dvls/chunk-WL5U2YIT.js:3:3484)
at Ne._next (https://test.internal.local/dvls/chunk-WL5U2YIT.js:3:3208)
at Ne.next (https://test.internal.local/dvls/chunk-WL5U2YIT.js:3:2935)
at https://test.internal.local/dvls/chunk-WL5U2YIT.js:3:5946
at In (https://test.internal.local/dvls/chunk-WL5U2YIT.js:3:2326)
at Ml.next (https://test.internal.local/dvls/chunk-WL5U2YIT.js:3:5785)

Same here,

Healthpage gives ok and certificate is also good. Seems there are more users with the same problem and this is a bug related to the latest update.

Hi hjobs,

Thanks for the follow-up, and for the stack trace and screenshots. You are right, this is a bug on our side and not your certificate. The gateway is healthy and the certificate is valid, your health check confirms that. The error is in how the Devolutions Server web interface reads the gateway certificate in the trust dialog: the certificate details come back empty, and pressing Continue and save then throws the "Cannot read properties of null (reading 'thumbprint')" error you are both seeing. Our development team has this logged, and retrying the add in the web interface will keep hitting the same point until a corrected build is out.

To line this up with the right fix on our side, could you confirm your environment: the exact Devolutions Server version you are on now, and whether the server is running under IIS or self-hosted. I will follow up here as soon as I have an update on the fix.

Best regards,
Michel

We run the latest versions for both server as gateway.