How to get your Unity LLAPI/WebSocket WebGL app to run under https with AutoSSL & stunnel

<continuing my “blog about whatever random issue I last dealt with in the hopes that some poor soul with the same issue will google it one day” series>

The problem

So you made your new Unity webGL game using the LLAPI and it works fine from a http:// address. But when you try with https, even with a valid https cert being installed, you get this error:

“Uncaught SecurityError: Failed to construct ‘WebSocket’: An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.”

This is your browser saying “Look, the website is https, but don’t let that fool you; it’s using a normal old web socket to send data under the hood which isn’t encrypted, so don’t trust this thing with your credit card numbers”.

Unity (at the time of this writing) has no internal support for what we really need to be using: a Secure Web Socket. So where http has https, ws has wss. So how do we connect securely if our unity-based server binary can’t serve wss directly?

A little background info about CPanel & AutoSSL

Note: I’m using CentOS 7 on a dedicated server with WHM/CPanel

Setting up your website for proper SSL so it can have that wonderful green padlock used to be a painful and sometimes expensive ordeal.

But no longer! Enter the magic of CPanel’s AutoSSL. (I think it’s using Let’s Encrypt under the hood as a plugin?) Behind the scenes, it will handle domain validation and setup everything for you. While it does need to renew your cert every three months, it’s free and automatic. Add four new domains? They will all get valid certs within a day or so, it’s great.

We can use this same cert to make your websockets secure as long as they are hosted at the same domain.

Setting up stunnel

This is an open source utility that is likely already included on your linux server box, if it isn’t, go install it with yum or something.

It allows you to convert any socket into a secure socket. For example, if you have a telnet port at 1000, you could setup stunnel to listen at 1001 securely and relay all information back to 1000.

The telnet connection has no idea what’s happening and sees no difference, but as long as the outside user can only access 1001, plain text information isn’t sent along the wire and one or both sides can be sure of the identity of who’s connecting.

Depending on the stunnel settings, it might be setup like https where the client doesn’t have to have any certain keys (what we want here), or it could be like a ssh where the client DOES need a whitelisted key.

A way to test a SSL port is to use OpenSSL from the command line on the host server via ssh. For example (keep in mind 443 is the standard https port your website is probably using):

<at ssh prompt> openssl s_client -connect localhost:443

<info snipped>
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=host.toolfish.com
issuer=/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4946 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
 Protocol : TLSv1.2
<info snipped>
Start Time: 1518495864
 Timeout : 300 (sec)
 Verify return code: 0 (ok)

Hitting enter after that will probably cause the website to an html error message because we didn’t send a valid request. That’s ok, it shows your website’s existing SSL stuff is working so we can move on.

So first edit your /etc/stunnel/stunnel.conf to something like this:

pid = /etc/stunnel/stunnel.pid

#we won't screw with changing this because we don't want to relocate/change permissions on our files right now
#setuid = nobody
#setgid = nobody

sslVersion = all
options = NO_SSLv2

#for testing purposes.. these should be removed later:
output = /etc/stunnel/log.txt
foreground = yes
debug = 7

[websitename1]
accept = 29000
connect = 80
cert = /var/cpanel/ssl/apache_tls/oversi.io/combined

[websitename2]
accept = 30000
connect = 20000
cert = /var/cpanel/ssl/apache_tls/oversi.io/combined

Next, still from the ssh prompt, run stunnel by typing stunnel.

Because we have foreground=yes set above it will run it in the shell, showing us all output directly, instead of in the background like it normally would. (Ctrl-C to cause stunnel to stop and quit)

Look for any issues or errors it reports. The .conf file I listed aboveshows how to set it up for two or more tunnels at once, you likely only need one of those settings.

The “websitename1” part doesn’t matter or have to match anything.

The SSL cert is the most important setting. You need to give it your private & public & CA info in the same file.

Now, initially, you might try to setup your keys using the files in ~/ssl/keys and ~/ssl/certs but they seem to not have everything all in one nice file including the CA certs. I figured out ‘bundled’ ones already exist in a cpanel directory so I linked straight to them there. (replace oversi.io with your website name)

If stuff worked, you should be able to test your SSL’ed port with OpenSSL again. In the example above under “websitename1” I told it to listen at 29000 and send to port 80, for no good reason.

So to test from a remote computer we can do:

(you did open those ports in your firewall so outside people can connect, right?)

C:\Users\Seth>openssl s_client -connect oversi.io:29000
Loading 'screen' into random state - done
CONNECTED(00000270)
depth=2 /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=oversi.io
 i:/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
 1 s:/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
 i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
<snipped>
-----END CERTIFICATE-----
subject=/CN=oversi.io
issuer=/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
---
No client certificate CA names sent
---
SSL handshake has read 5129 bytes and written 453 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
 Protocol : TLSv1
<snipped>
 Key-Arg : None
 Start Time: 1518497616
 Timeout : 300 (sec)
 Verify return code: 20 (unable to get local issuer certificate)
read:errno=10093

Despite the errno=11093 and return code 20 errors, it’s working and properly sending our CA info (“cPanel, Inc. Certification Authority”).

Or, easier, let’s just use the browser instead for this one since we’re connecting to port 80 if it works in this case:

https://oversi.io:29000

It worked, see the green padlock? Oh, ignore the error the website is sending, I assume that’s apache freaking out because the URL request is different from what it’s expecting (http vs https or the port difference?) so it can’t match up the virtual domain.

From here, you should probably remove the debug options in the .conf (including the foreground=yes) and set it up to run automatically. I just placed “stunnel” in my /etc/rc.d/rc.local file. (this gets run at boot)

Actually connecting using the Unity LLAPI

Congratulations, everything is setup on the server and you’re sure your web socket port is listening and ready to go.

While your server binary doesn’t need to change anything, your webgl client does.

You now need to connect to WSS instead of WS. Example:

try
 {
   _connectionID = NetworkTransport.Connect(_hostID, "wss://oversi.io", portNum, 0, out error);
 }
 catch (System.Exception ex)
 {
   Debug.Log("RTNetworkClient.Connect> " + ex.Message);
 }

That’s pretty much it. If someone doesn’t care about https and decides to play over http, it still works fine. (internally the websocket code will still connect via wss)