Secure Websocket 404 error

Hey everybody,

This is a continuation on this thread: lucee link. I now got the websocket plugin working on localhost and on the server through a local domain on HTTP (thx for that!). Now I’m trying to get it to work through HTTPS. This is also the part where I got stuck years ago and I hope somebody here can point me in the right direction!

What is the situation
I’m trying to get the most simple example working, so I know it’s not the code. So I’ve implemented the EchoListener and client code on a domain we have. This code is exactly the same on the working HTTP example (just another URL). In the picture below you can see a total view of the problem. I’m on a HTTPS domain, trying to call the EchoListener on the same domain through WSS. But I get a 404 error. I’ve tried everything to changing ports, place of the code, code outside the domain etc.

We have a certificate and this is also for websockets (I think). I know that the websocket listener is on because when I call the “WebsocketServer” function twice I get an error that it is already defined.

What may work
I’ve found a thread here on the github page: link and he talks about a apache proxy that (I think) converts a WSS to an WS on the server. Is this maybe the way to go? How could this be done with a Windows server IIS + tomcat installation.

I hope somebody can help us out! It’s really frustrating because we have a beautiful chat application, but we cannot use it because we’re now using HTTPS. And a general 404 error is not enough information for me to understand what is going on. I’ve also seen ERR_CERT errors and ERR_TIMEOUT.

If anyone has questions or want more information, please just ask!

Good day,

Hi @DrunkenMoose,

I played around with WebSockets on Lucee not so long ago and found the following post very helpful in getting a proxy setup in IIS:

You need to install the Application Request Routing module, URL Rewrite Filter, and the WebSockets role on IIS.

Configure the Application Request Routing module and URL Rewrites and possibly the adjustment to the Tomcat config suggested in the post.

This should proxy both ws and wss requests to the http endpoint.

Hope this helps.

All the best,



here I am again to add some information to @martin. Do not know if you are still using tomcat as a stand alone webserver.

Igal Sapirs Websocket Extension works in Tomcat with plain HTTPs setup out of the box. I had to dig around to make it work a while back. If you want to set up another webserver in front of tomcat (for IIS or Apache2), you’ll need another approach. For IIS please follow @martin approach. For those who want to add HTTPS for Tomcat in stand alone mode, and want to try a self signed certificate on localhost, here is a working solution for WIN10 that I’ve put together from various sources. But it might work very similar on other OS. Here are the steps:

  1. Check if you have openssl installed on your machine. To verify you can open a cmd terminal and type: C:\Users\username>openssl version. If not installed already, install openssl for windows on your machine. To do that you have these options:
  1. Open a cmd terminal / in case of using cygwin open a cygwin terminal
  2. Create a directory e.g. D:\mycerts by typing D:>mkdir mycerts
  3. Change into the created directory: D:>cd mycerts
  4. Open a text editor and create a file called D:\mycerts\domains.txt with the following content:

distinguished_name = dn

  1. In open cmd terminal enter the following command:
openssl req -x509 -out localhost.crt -keyout localhost.key -newkey rsa:2048 -nodes -sha256 -subj /CN=localhost -extensions EXT -config D:\mycerts\domains.txt

This command will create two files D:\mycerts\localhost.crt (signed certificate) and D:\mycerts\localhost.key (private key)

  1. enter the following command:
openssl pkcs12 -export -in localhost.crt -inkey localhost.key -out localhost.p12

This command will export the certificate as a tomcat readable certificate named D:\mycerts\localhost.p12. You’ll need to enter a password and verify that password for that command. This password you’ll need to add to tomcats server.xml during the following steps.

  1. Open {installation path}\lucee\conf\server.xml and search for “8443”. You’ll find some configuration tags for port 8443 as comment. Place the following tag as an activce tag:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
           clientAuth="false" sslProtocol="TLS"
           keystoreFile="D:\mycerts\localhost.p12" keystorePass="YourPasswordFromStep7"
  1. Restart Lucee/Tomcat
  2. Open in Chrome: https://localhost:8443/?username=User1 and open its WebDevTool by pressing F12 (with the console-view)
  3. Open in Firefox https://localhost:8443/?username=User2 and open its WebDevTool by pressing F12 (with the console-view)

You’ll see that wss:// will be used without any problem. For other tomcats connector port=“8443” configurations attributes in server.xml, please see tomcat reference page here.

Best wishes to you and the rest of all Lucites!

Dear Martin,

That sounds very interesting and I will continue to look at this in the weekend. But a quick question: I think this solution is for a HTTP domain to have a normal WS connection? Because we already have a working websocket WS connection on normal HTTP domain. The problem is when we implement the same code on a HTTPS domain that it stops working.



Thanks for the extended answer! Our end-goal is to have a wss:// connection on a https:// domain. But this could really help to have a better understanding on how it works and I want to try to have this working on my local lucee.

I ran into some issues with openssl (is doesnt want to generate the .crt and .key file) but I will work this out in the weekend. If I can see the websocket perform on localhost through wss then that would give more confidence that this could work on our Windows server.

(coming back to my post)
Still the 404 error irritates me because you would think the page is not there, but I think something else is going on.


The IIS proxy lets you have a secure wss/https connection to IIS, proxying to an insecure ws/http connection on Tomcat. In some circumstances that may be enough if the Lucee instance is on the same machine as IIS.

If you want Tomcat to have a wss connection, you will need to look at the additional steps that @andreas details.

All the best,


Hi @DrunkenMoose,

In case of a final setup with IIS in front of Tomcat, I would suggest to stop trying my approach with stand alone tomcat. You won’'t need it at all in your final setup. When using IIS the complete connection behind the scenes is without TLS(SSL) over Lucees default port 8888. In your case I would install IIS on your local dev machine, and start from there with @martin solution.

Hello Martin (and Andreas),

I’ve taken another look at the Websockets and followed your steps for implementing the IIS proxy. And suddenly I got a 502 error websocket error. So for me that was good news because I see another error. After looking at the steps a bit I changed “{HTTP_HOST}” to the server IP and OMG i got a connection through the HTTPS domain! The image in the first post is now:

So because I have the server IP as a redirect I understand it goes to another listener outside this domain.

I still have an error in the chat application because the connection is immediately closed while using the ChatListener. See following image (I removed our domain name from the image):

I think it is because I see an error in the websocket log file while trying to connect the chat.
The following error:

The username doesn’t exist in the property. But if I look at the Lucee websocket chat example then they also use the username property.

But still I got some life instead of the 404 error, so THANKS! I will continue to get it all working again and I hope we get a steady websocket connection. But the information you guys provided have made me understand the websockets a little better and how the connection works. I also hope this thread help others who have difficulty implementing the websocket protocol. It’s a cool technique and a must have for notification/chat functionality.


P.S. if you understand the username error then don’t hesitate to give a clue;)

1 Like