Proxy error when trying to access website

Hi!

The error you pasted is benign and not very relevant (we are using length framing).

Are you observing specific problems when running the website session?

If so, it may be relevant to check for latest file (after you reproduce the issue) in the folder `%AppData%/jetsocat`, on the same machine as RDM.

Let me know!

Ah, the error in the logs is as follows:

2025-06-05T13:45:20.959548Z  INFO jetsocat: version="2025.1.0"
2025-06-05T13:45:20.960131Z  INFO jmux: jetsocat: Start JMUX proxy
2025-06-05T13:45:20.960187Z  INFO jmux:open_jumx_pipe: jetsocat::pipe: Connecting WebSocket at wss://10.29.90.98:7171/jet/jmux
2025-06-05T13:45:20.962619Z  INFO socks5_listener_task{bind_addr="127.0.0.1:65398"}: jetsocat::listener: Start listener
2025-06-05T13:45:21.654938Z ERROR jetsocat: couldn't open pipe: WebSocket connect failed: WebSocket handshake failed: TLS error: native-tls error: Er is een certificaatketen verwerkt, maar de keten is geëindigd bij een basiscertificaat dat niet door de vertrouwenslijstprovider wordt vertrouwd. (os error -2146762487): native-tls error: Er is een certificaatketen verwerkt, maar de keten is geëindigd bij een basiscertificaat dat niet door de vertrouwenslijstprovider wordt vertrouwd. (os error -2146762487): Er is een certificaatketen verwerkt, maar de keten is geëindigd bij een basiscertificaat dat niet door de vertrouwenslijstprovider wordt vertrouwd. (os error -2146762487)
 

The error is in Dutch and claims that certificate chain validation stranded at a root certificate which is not trusted. Is this about the self signed certiticate of the gateway? Should this be distributed to all clients?

Oh! If you are using a self signed certificate, yes it needs to be trusted by all the clients. Said differently, the root certificate must be trusted by all the clients, but in the case of a self-signed certificate, the root certificate and the leaf certificate are the same.

Hmm okay, I'm going to chew a bit on that. I could either distribute the certificates to our clients or replace the certificate with a proper certificate from a trusted CA.

I followed the instruction on Devolutions Gateway configuration on Linux - Devolutions Documentation . The instructions there tell you to create a selfsigned certificate and trust it on the devolutions server, which I did. I was under the impression that the certificate was just used to secure the connection between the server and the gateway.
If I were to use a public certificate, should I still use the subjectAltname with the IP field? And do I still need to explicitly import the cert on the devolutions server or is it good enough if the chain can be verified?

The instructions there tell you to create a selfsigned certificate and trust it on the devolutions server, which I did. I was under the impression that the certificate was just used to secure the connection between the server and the gateway.

It sounds like the instructions in the documentation you mention are a little bit vague: yes this certificate does secure the connection between the Devolutions Server and the Devolutions Gateway, but some client to gateway features also rely on this certificate for security purposes. It’s not the case of plain TCP opaque forwarding we do for RDP connections. The reason is that the actual RDP payload is not visible to the Gateway: a TLS tunnel is opened between the client and the final target (RDP server), and Devolutions Gateway only sees encrypted traffic. However, in the case of website entries, a generic secure proxy tunnel between the client and the gateway is opened first. The Gateway can see what goes through that tunnel (although some protocol includes yet an extra layer of encryption), and thus we need to ensure the gateway is legitimate before allowing the connection.

I’ll let know our documentation team so they can improve this.

I could either distribute the certificates to our clients or replace the certificate with a proper certificate from a trusted CA

Indeed, you have two options:

1. Distribute the Certificate:

• Distribute the self-signed certificate to all client machines to ensure it is trusted across the network. This involves importing the certificate into the trusted root certificate store on each client.
• The self-signed certificate could be a CA that you use to create intermediate and leaf certificates, so that you can install a leaf certificate on the Gateway instead of a root certificate, but you still need the root to be trusted everywhere.
• An efficient way to do that on Windows is to use GPO (Cert Auth setting), and on Linux you could use tools such as Ansible, but there is no standard.

2. Use a Proper Certificate from a Trusted CA:

• Obtain a certificate from a trusted Certificate Authority (CA) such as Let's Encrypt, which is widely recognized and trusted. This would simplify the process as there would be no need to manually distribute the certificate to clients, assuming the chain can be verified.

If I were to use a public certificate, should I still use the subjectAltname with the IP field

For the subject name, you need to use the host you want to put in the access URI, be it an IP address, a DNS name or any other kind of local hostname.
In the case of a public certificate, if you are able to obtain such a certificate, it will works, but I would be surprised if you could get your hands on that in the first place.
For instance, with Let’s Encrypt, you need to own a DNS domain, and configure things in such a way that Let’s Encrypt can perform a challenge which includes poking the machine found by resolving the desired hostname from Let’s Encrypt’s servers.
In practice, all you can use in this situation is a registered domain name.
If you would rather keep everything internal, you’ll likely need your own self-signed certificate.

do I still need to explicitly import the cert on the devolutions server or is it good enough if the chain can be verified?

For both the client and the server, as long as the chain can be verified (as long as it’s possible to reach a trusted root), everything is fine.

Let me know if I there is anything else I can do to help you!

Best regards,

Thanks for the elaborate answer, this gives a lot of insight!