Your comments

the main thought that comes to my head is, you ready...

How do you know your install base?  When I bought licenses from you I didnt tell you what platform I was running on.  You just know that I'm on premise hosted.   Is nearly every linux customer on premise hosted?  I can't Imagine that's true either. 

Has your sales people ever called me since I bought the product to say "Hey, just wanted to follow up and see how you like it.  if you plan on renewing, etc. etc.  Oh what version you running?  We have new versions available.  Your running windows right?    Nope.  Never.   

While I think that your development dollars on linux seems silly to your superiors you should tell them your dead wrong.   Not sure how you guys are doing the whole "Cloud" version of your product.  My guess is that CW is hosting these with some kind of AWS integration to spin up a new VM running windows.   How costly is that compared to Linux?  Can probably save CW thousands of dollars literally and customers wouldn't even know the difference.  They would just pay the same bill.   

Think the writing on the wall is silly and stupid.    Force us to windows, we will move on to other products.  PERIOD.

I really, REALLY want to know how you know who your customers are. 

Sorry.  I dont think as many people are on Windows as YOUR COMPANY thinks. 

And (for what its worth)  thank you as well for the explanation. 

Chris, While I tend to agree, its not that simple.  People have lost business over the ability to not be able to support their customers with a tool purchased to do just that.   While there are other options in the marketplace, some of us have come from a long journey with ScreenConnect and have depended on this product for a long time.  This is an issue that ConnectWise needs to fix.  This is why we all pay for support. There is no real workaround.  Windows Server isn't really an option for a lot of small business due to the microsoft licensing model associated with Windows Server, CALs, etc.   Honestly, not sure why this company (connectwise) hasn't really paid more attention to their Ubuntu/Debian line of code because it could save them thousands of dollars passed on to the customer or just pure profit if they moved their "cloud" version to linux servers.      

My Renewal for SC comes up in august and I am really hoping its fixed by then or I might be one of their customers that looks for another product.  Lets face if, if I'm going to go though the pain of a redeploy of 100's of unattended access clients -- it will be to switch to another product, not deploy an old version of this product. 

Was hoping that SC will extend our support free of charge for at least the time it took to fix this issue.   Then at least they acknowledge that it took to long and give us a bit of a reason to stay onboard the sinking vessel. 

Any updates?   Linux users who have the software installed have not been working since 19.4.  The 20.1 release is not stable at all.  Are there any plans to actually fix this or should I basically stop renewing support for a product that has no support. 


Assumes you have  your own REAL cert.

Get your cert in PEM format.   i.e.   

open all of your certs from whoever in notepad or whatever and combine all these in this order.



name file  ending in mycert.pem (probably not required but to lazy to check if it is)

as root:

apt-get install haproxy -y

mkdir -p  /etc/haproxy/certs

-->  put your cert,   the above directory

rm /etc/haproxy/haproxy.cfg 

vim or nano  (your choice  nano if your in experienced)  /etc/haproxy/haproxy.cfg


log local0 notice
maxconn 2000
user haproxy
group haproxy
tune.ssl.default-dh-param 2048
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
stats socket /run/haproxy/haproxy.sock mode 660 level admin
stats timeout 2m # Wait up to 2 minutes for input
ssl-server-verify none

log global
mode http
option dontlognull
retries 3
option redispatch
timeout connect 5000
timeout client 5m
timeout server 5m
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

listen Web-Services
bind *:80
bind *:443 ssl crt /etc/haproxy/certs/
mode http
option httplog

redirect scheme https if { hdr(host) -i } !{ ssl_fc }

stats enable
stats uri /stats
stats realm Strictly\ Private
stats auth <username>:<password> 

acl host_help hdr(host) -i

use_backend ScreenConnect if host_help

backend ScreenConnect
balance roundrobin
option httpclose
option forwardfor
cookie JSESSIONID prefix
server node1 cookie A check
reqadd X-Forwarded-Proto:\ https
reqadd X-Forwarded-Port:\ 443


Grab the info between the <code> and </code> and copy it 

paste it in the file

Adjust the username and password for stats line  (stats auth blah blah)  

change to  whatever it is that you got going on. 

don't touch anything else (unless you would like to adjust the IP rather then using the loopback to say  your boxes internal IP)

verify that haproxy is good with your config:

haproxy -c -f /etc/haproxy/haproxy.cfg

(  -c  is check   -f is file)

once good restart haproxy.

Now.   If you get errors or your already using  80 and 443 for other things (mainly screenconnect) then  you have to adjust 
your web.config file.

This is where shit sorta gets interesting.

typically if you installed this and didn't change the default install path its...



web.confg is there

make a backup of the file.

cp  /opt/screenconnect/web.config  /opt/screenconnect/web.config.backup_2019-03-25 

yes you should date the file even know unix will timestamp it anyways.  (its good habit)

vim or nano  /etc/opt/screenconnect/web.config

look for a line like this:

<add key="WebServerListenUri"  value="https://+:443/">

change it to this:

<add key="WebServerListenUri" value="http://+:5000/">

After all is said and done 

Screenconnect will restart and be listening on :5000 (port 5000)   you can verify by going to   <server's ip:5000> in a browser without HTTPS. 

now just restart haproxy to get it up and running again now that the ports are not conflicting. 




OK.  so I think its ridiculous how this thread has become this.   

1) your not going to go to another product, because your all grandfathered into the prices.  Which is 90% less then other competitions solutions.  If your going to go do that then go buy Bomgar's solution at 5k with yearly maintenance supports.

I still agree that CW should have fixed this but the reality is they are having a hard time because of the way that chose to fork mono.    It comes down to do you really want new features and bug fixes or do you want SSL working.  

NGINX takes approx 10 minutes to put infront of this and handles SSL rather decently.   

I've recently been playing with HAPROXY which basically does the same thing only FAST.  REALLY Fast.  The downsite to HAPROXY is you need to have a PURCHASED CERT.  

ConnectWise.  Feel Free to delete this thread if you want or lock it off for future comments.  

If anyone needs help with SSL via NGINX Reverse Proxy or HAPROXY feel free to email me directly.  

Prerequirement:   You must be running linux (preferably ubuntu 14-18, debian or similar debian platform).

windows or linux?   what version of linux?

Happy to help.  Unfortunately I think I've realized its impossible to script for every situation that is out there.   Script sorta works best if you never setup SSL in the first place on ScreenConnect.  

Honestly, if they drop linux support it will be the last time I ever renew the license, and whatever version I end up on will be the last type of thing.   I can't imagine running windows after using Linux servers for the past 10 years.   I don't even run windows domain controllers thanks to Univention Corporate Server (UCS).    Yes windows desktops are still in the environment but I find it hard to move away from it as a desktop platform.    

Hope ConnectWise/Screenconnect really isn't thinking about moving away from linux support.    Honestly, I cant believe their hosted servers are running on windows.   Paying for a windows server license + this product,  NO WAY!   

Forget it.

The SSL thing to me isn't a big deal with reverse proxy, it works and its very stable.   Id rather have them keep working/releasing updates on what we have then drop support for linux.   

I do agree though, that they really should have supported this out of the box, with LetsEncrypt integration and the whole bit.

ok, so mine is a bit different 

<add key="WebServerListenUri" value="http://+:8080/">


<add key="RelayListenUri" value="relay://+:8041/">


you need to remove this as it was once needed for HTTPS directly for screenconnect/mono to handle these requests:

add key="RedirectFromBaseUrl" value="http://*/">
add key="RedirectToBaseUrl" value="">

because NGINX is doing this redirect for you.   

Essentially your forwarding your traffic to NGINX rather then screenconnect, NIGINX will handle your HTTPS, so then NGINX is talking to your server directly via loopback -to- screenconnect on a non-HTTPS port, in the above config port 8080 HTTP, which is not exposed to the internet.  

Your RELAY PORT,   RelayListenUri is for the unattended clients to talk to your server as well as anyone in an active session doing remote desktop type behavior.   Do not change this port as it will have disruption.

oh one more thing,  technically a ton of connections is somewhat a misleadinge.  You should have EXACTLY the same amount of connections as you have unattended clients installed (out there) that are currently online in screenconnect.    and +1,2, or 3 less or more if have someone supporting a session at the time your checking netstat.