Is Websocket Secure (wss) supported?


I’m seeing some strange behavior whenever I open a websocket with wss in the URI instead of ws. It instantly returns an error on open, and refuses to connect. With a standard websocket, it connects just fine.

Any ideas what’s happening or if there’s a feature I’m not taking advantage of?

If not, is this a bug?

Change the websocket url below to “ws://” to see a working version.

For this demo, I added this code to the UI kitchen sink to test. Here’s the error object it returns:

let ws = new WebSocket("wss://");

ws.onopen = function (e) {
	console.log('Open: ',e);

ws.onmessage = function (e) {
	console.log("From Server:" + e);

ws.onerror = function (e) {
	console.log('Error: ', e);

Yes; wss is supported. I just tried from a debugging session in Ps, and it worked fine. Perhaps the server was having problems? Or, possibly, you’re behind a proxy? If you log e.message when you get the error, what’s the response?

Well that’s strange…

No proxies here, and the error is an unusual object (screenshot below) with no message.
I just tried again as well and same result. I had a colleague test this same code in his own playground, and he encountered the same error object.

Just to be super, triply sure:

I had another developer in Nevada and one in Cali attempt the same thing. They got the same result (screenshot below).

Is there a way we can get the version of our environment that might help track down if perhaps we’re behind on an update? (Or is it only the Photoshop version we’d need to help debug?)

Corrected screenshot to include e.reason and e.message:

So, your screenshot looks like Windows – and on my Windows machine, I can confirm that the request is failing. I’m not sure why, though – may be something SSL related since the failure is so immediate with so little information.

You might try with your own websocket server to see if you get more information as to the failure. I’ll also forward this along internally, since there may be a bug on our end. This used to work fine, but it may be a regression.

Thanks Kerri! You’re correct. I’m on Windows.

I confirmed with our own websocket server as well and got the same result. Unfortunately, no additional information was available.

I also confirmed that this works on my Mac, so that definitely narrows it down to a Windows issue!

Any ideas where I might be able to get updated on if/when it’s getting fixed?

Kerri, a little bit of information to pass along:

We traced the tcp activity at the server level where the websocket endpoint lives, to see if there was anything unusual going on.

As far as we can tell, the websocket handshake appears to be functioning as expected, and then something inside Ps breaks after, perhaps at the completion of the handshake on open.

Just wanted to provide a little more info to help debug!


It sounds like the initial handshake is working OK, but the transition to websocket protocol is breaking… strange! We do use boringSSL for Windows, so I wonder if there’s something going on in the SSL layer…

Can you make fetch HTTPS requests to the same server without issue? That might provide some leads.

I confirmed we can do a fetch request over https!

Any chance someone looked into this bug?

Just a heads up, Kerri. Tested on the newest 22.2.0 and the same issue still exists.

Any chance it’s being checked out, or is it lost in the ether?

I’ve asked the team to take a look; will get back to you with any updates. I think I missed sending this to them the last time – my apologies.

Thanks Kerri! The help is much appreciated.

As soon as this is fixed I can release my new plugin to replace the old CEP stuff. :smiley:

Hey Kerri!
Any news from the team on this bug? :slight_smile:

I’ll check with the team.

Hey Kerri! Rollin’ the dice to see how lucky I might be for April!

Any luck? haha

Ok – update!

We’ve figured out the root cause of the problem, and there’s nothing you can do on the server side to rectify it. The issue is that the certificate store isn’t getting loaded correctly, and so UXP closes the connection as if it found a certificate it couldn’t validate.

I’ve got the team looking into the fix. I’m hopeful it can be in place for the June release of Ps. Cross your fingers. :slight_smile:

If you want to test things out before the fix, there’s a workaround – get your hand on a cert.pem file (Mac or Linux should do) and copy it to C:\etc\ssl\cert.pem. Once done, your WSS connection will start working. This is not a solution for end users, but would unblock things enough to test the rest of the plugin.


You are AWESOME. Thank you for following up and tracking this down!

Looking forward to that June update!

Two months of crossed fingers later… haha

So how’s it looking, Kerri?

Is June gonna be a victory month?!

It’s fixed as part of UXP 5.1. As to when Ps releases w/ this, that’s a harder question, since it’s up to them when they pick it. Not much longer to wait, though.

If you aren’t already, please join the prerelease. You’ll get a version that works there earlier than the general public. Note, though, that the prerelease is still on 5.0, so don’t get your hopes up just yet. :slight_smile: