Hi all 
,
I am trying to connect to the Octoprint websocket from a Node.js server using the 'sockjs-client' node-module.
Connecting via http like this:
const ioClient = new SockJS('http://localhost:50001/sockjs');
works fine (Port 50001 is a SSH tunnel to the Octopi), but as soon as I switch to https (using a different tunnel) the .closed method is called without an error and the logs on the Octopi show no sign of a request.
Since I already suspected the self-signed certificate to make problems I tried the 'ws' node-module witch offers the option { rejectUnauthorized: false } and it worked!
I have also been able to connect to the socket over https using the 'Smart Websocket Client' Chrome-Extension.
Is the self-signed certificate the source of the problem and if so, how does the octoprint web-client solve it?
Thanks in advance and best wishes 
Matthias
This is the nature of self-signed certificates; the originating Certificate of Authority (yourself) isn't included in some public/trusted list of CAs. The method you've used is probably the easiest to implement in your case.
In theory, you could instead use a certificate as generated by LetsEncrypt. Since theirs would be signed with a CA which is included in the public list, then it might work fine without that workaround.
Lastly, there's probably a way in which your workstation could import the CA information, as created earlier, and then from your workstation approve/import/trust it. Teaching how to use openssl though is a bit beyond the scope of providing support for OctoPrint, to be honest.
Research: "extract certificate", "install a CA-signed certificate"
Thanks for the quick reply!
I'll look into approving the Certificate Authority on my Server and otherwise just use http instead. https is not crucial to my application but would be a nice-to-have.
I guess I hoped there would be a quick fix like the rejectUnauthorized: flase option, since this is to my understanding essentially the same as approving the authority yourself 
Cheers
Matthias
1 Like