logo
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

2 Pages<12
Options
Go to last post Go to first unread
shawnkhall  
#51 Posted : Tuesday, September 19, 2017 2:39:34 AM(UTC)
shawnkhall


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/6/2014(UTC)
Posts: 288
Man
United States

Thanks: 7 times
Was thanked: 23 time(s) in 21 post(s)
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
srutledge  
#52 Posted : Wednesday, September 20, 2017 4:55:35 PM(UTC)
srutledge


Rank: Guest

Joined: 10/7/2016(UTC)
Posts: 5
Location: Georgia,US

How does Piggybacking actually work? Does this mean that IIS is already running on the server? If it running, then isn't it already listening on that port?
shawnkhall  
#53 Posted : Wednesday, September 20, 2017 5:11:18 PM(UTC)
shawnkhall


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/6/2014(UTC)
Posts: 288
Man
United States

Thanks: 7 times
Was thanked: 23 time(s) in 21 post(s)
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.
scuneedinghelp  
#54 Posted : Sunday, January 21, 2018 12:37:21 PM(UTC)
scuneedinghelp


Rank: Guest

Joined: 1/21/2018(UTC)
Posts: 4
Location: North Carolina

I have having a lot of trouble getting 80 traffic to forward to https://:443

I am running on Ubuntu
Version 6.4.15361.6527
My SSL Cert is in place
https://mydomain.com - loads fine
https://www.mydmain.com - loads fine
http://mydomain.com - does not load/redirect
http://www.mydomain.com - does not load/redirect


I followed the directions about the HttpsRedirectModule.cs file to the App_Code folder I created

Here is my current web.config

<add key="WebServerListenUri" value="https://+:443/">
</add>
<add key="RedirectFromBaseUrl" value="http://*:80/">
</add>
<add key="RedirectToBaseUrl" value="https://*:443/">
</add>


Any suggestions. I have made some adjustment I have forgotten all the ones I have tested.

Thanks for any help you can provide.
Scott  
#55 Posted : Monday, February 5, 2018 12:35:10 PM(UTC)
Scott


Rank: Administration

Medals: Level 4: Wise Old Owl! Received 100 Thanks!

Joined: 3/28/2014(UTC)
Posts: 2,726
United States

Thanks: 3 times
Was thanked: 332 time(s) in 286 post(s)
Quote:
http://mydomain.com - does not load/redirect


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).
ScreenConnect Team
scuneedinghelp  
#56 Posted : Tuesday, February 6, 2018 1:30:45 AM(UTC)
scuneedinghelp


Rank: Guest

Joined: 1/21/2018(UTC)
Posts: 4
Location: North Carolina

I did finally get this to work after many tries. The specific part was 100 percent my problem. In my case, not sure for everyone else, the redirect to address has to include the domain name. I was trying a much wide https://*:443/, added mydomain.com:443 and it started working.

Thanks
KeeganJacobsonStryker  
#57 Posted : Tuesday, July 24, 2018 8:09:19 PM(UTC)
KeeganJacobsonStryker


Rank: Guest

Joined: 7/19/2018(UTC)
Posts: 5
United States
Location: Duluth, MN

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

Users browsing this topic
Similar Topics
HTTP redirect to HTTPS, relay on separate IP port 80. Could not establish trust relationshi (Advanced Customization)
by gcouch 5/14/2014 10:30:02 PM(UTC)
2 Pages<12
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.