I don't understand why everyone is running it this way, anyway. It's *much* easier to just piggyback onto an existing site that supports HTTPS by setting the WebServerListenUri to a subdirectory on the site (that doesn't already exist), such as:

key="WebServerListenUri" value="https://example.com:443/support/"

I suspect most people that have actually bought this software are running a server and at least one site, so this process integrates the ScreenConnect directly into the site as easily as changing this value.

Specifics here:
https://docs.connectwise...existing_SSL_certificate

yes and yes. it's a function of .net and IIS - and by far the simplest way to set it up. i spent *hours* trying to get SC to work via SSL when running on its own, but the piggybacking option (once i finally discovered it) took literally 10 seconds to setup. the hardest part was browsing to the web.config file to make it work.

Since that doesn't work but https does, did you remember to add the WebServerAlternateListenUri setting to the web.config? You mention all of the other steps except that one.

Also, it may help to tweak/change the RedirectFromBaseUrl to something a bit more specific (even just for testing).

This thread has successfully helped us move from running Web on Port 80 and Relay on Port 443, to now having an HTTP to HTTPS redirect and still having the relay running on 443.

It took many iterations and I went through the official documentation for the SSL Configurator and comments here and ran into a few hurdles along the way and some snafus until we finally settled on a configuration that works really well for us and I thought I'd document my experience here for others that may be interested. This project was a long time coming, but Google's recent push to mark HTTP sites as in-secure helped make this project a priority.

We initially started with the SSL Configurator tool, which actually worked very well and was slick. It did work, but it provided a couple challenges with that implementation for us. Firstly, SSL was handled and terminated on that box itself, we've got a Load Balancer available that provides SSL termination, so any time the cert would need to be regenerated or renewed it would mean having to manage and update that box individually as well (not good for scaling / central management as it would be a one off). Not a deal breaker by any means and something we were willing to accept. But the kicker was that this didn't accommodate for an HTTP to HTTPS redirect. So to this thread we came.

I was able to get the HTTP redirect working by following through the posts here and I got it working in a couple different ways. I used Snapshots on our VM to help iterate with my testing, and I was able to get it working both natively through web.config modifications, as well as handling it through IIS. IIS did seem "simpler" in a sense, but if I had to choose I preferred having it all native/handled from the same Screenconnect web.config to reduce attack surface from having less services installed and having to keep those other services up to date and managed and hope they don't break. Now this is where the problem with this implementation method started to surface, at first I thought about having Relay run on Port 80 and just do Web on 443, but you can't have Relay on Port 80 and have an HTTP redirect (Port 80) running at the same time since they both want to use Port 80.

This is when I came across the following post in this thread: https://blog.roushtech.n...reenconnect-setup-nginx/

At first I thought about doing a similar setup with Nginx because really everything that is detailed here is exactly what were looking for with our configuration. But we fortunately have access to a Load Balancer / Proxy / SSL Termination device that we put applications behind, and with some minor changes to how we had the application configured based on his thread we could essentially do the same thing without having to use additional resources and create a VM running Nginx, since we could do the Proxying/Load Balancing with our appliance we already had.

So we essentially did the same thing as the Nginx post, we decided to run Web on Port 8040 (Default) and then ran Relay on Port 443. We did not have to do anything with an HTTP to HTTPS redirect, as we were handling that all externally at this point. This did add some "complexity" and extra resources to our configuration, but in my opinion it is the more proper configuration anyways - we needed an extra public IP for the relay service and an appropriate A record for the DNS entry.

Here are some pros/cons to our configuration:

Pros-

• We can manage SSL certificates centrally (via load balancer), so don't need to update SSL on that box itself
  
• This gives us HTTP to HTTPS redirect. I would argue this is important, but if you update all URLs otherwise or tell users to go just to HTTPS could work around it.
  
• Minimal "hacking" to the web.config on the box itself with a more standard configuration, which hopefully will make it more compatible in the future for upgrades
  

Cons or potential deal breakers-

• This configuration requires additional resources (A Load Balancer, or a separate server to act as one/proxy such as Nginx)
  
• An additional Public IP for your relay
  
• An additional DNS record (just for the relay, example screenconnectrelay.contoso.com)
  

Edited by user Tuesday, July 24, 2018 8:15:18 PM(UTC)  | Reason: Not specified