Add Let's Encrypt support to base screenconnect functonality
With LetEncrypt now in production It will be an ansome feature if ScreenConnect woukd support it strait at install.
you could offert ssl support out of the box for all client raising the security of your application and reducing the effort for end user to set it up.
Answer
This is a very good idea, and will be much more if it's possible thru the web interface like cPanel do.
See website here for example: https://letsencrypt-for-cpanel.com/
Maybe it can be an extension with a one-time fee.
And after that we can just forget about renewing our cert.
@Koncept Technologies "Maybe it can be an extension with a one-time fee."
No way! The whole point of Let's Encrypt is that it is free. Charging to implement ACME is unethical. The point of Let's Encrypt is to make HTTPS usable by everyone.
Charging, even small amounts, is against the point - you can already get cheap certs for a few dollars. The point is certificate authorities can no longer justify charging for DV when it can be automated for free.
I'd only support it if 100% of the proceeds were a donation to Let's Encrypt.
I almost didn't find this one because of the spelling. Can you update the title to include "Let's Encrypt" so we can try to get more traction on this one? Would love to see the ability to generate/install a Let's Encrypt certificate right from within the GUI. Thanks!
+1 for this. Easy encryption of the web interface should be pretty standard now where remote access is used.
Great feature, thought I already have it running with SSL/paid certificate, this is a must have. Make it possible to add multiple host names in the configuration of Let's Encrypt!
Agree, this is a no-brainer add-on. We have been moving almost all our certificates to Lets Encrypt as they expire. I never understood why certificates were so expensive. Always felt like I was getting ripped off by cert companies.
There are plenty of open source apps like winsimple to use as a guide.
+1 this is a great idea, I'm surprised so many others have thought about this too!
+1 in times of encryption I agree as well that this has to be a no-brainer add-on.
+1 Anything I say here would just repeat what others have already stated. I would love to see this!
+1 for this! We need to secure connectwise easly without some hoops to go thrue!
YO YO make it GO!!! Get the review over with and lets move on the encryption!!
PLEASE!!
We've planned to configure Let's Encrypt for the system, so a way to get Control to automate this process would be highly appreciated.
This would be awesome if it could be implemented by you guys. Anything to increase security especially now that hackers are targeting MSPs to propagate Crypto through MSP tools.
HUUUUUUUUUUUUGE +1 please! I could afford another license if I didn't have to pay for a certificate!
on Prem Screenconnect using Linux Nginx Lets Encrypt ...
Nginx as web proxy, Lets Encypt pretty straight forward using the certbot see https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/
NGINX config file ...web server working .. need to get relay working on port 443 so it will work on more firewalls as business routers will most likely block port 8041 which is the relay port fro screenconnect
server {
listen 80;
listen [::]:80;
server_name example.co.uk www.example.co.uk relay.example.co.uk sc.example.co.uk;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;localhost
proxy_set_header X-NginX-Proxy true;
proxy_pass http://localhost:8040;
proxy_redirect off;
}
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.co.uk www.example.co.uk sc.example.co.uk;
ssl_certificate /etc/letsencrypt/live/example.co.uk/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.co.uk/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://localhost:8040;
proxy_redirect off;
}
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name relay.example.co.uk;
ssl_certificate /etc/letsencrypt/live/example.co.uk/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.co.uk/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://localhost:8041;
proxy_redirect off;
}
}
Another vote for Yes, please get Let's Encrypt support into ConnectWise Control ASAP!
As you're not using a standard web server, support for LE should already be built in.
ScreenConnect doesn't sit on top of a standard web server (such as Nginx / IIS / Apache) - it implements the web server as it's own custom service. As such the standard / known ways of configuring LE for standard servers aren't applicable. That means SC need to take responsibility for building this support in, and I suggest should really have already done this.
why cant they just use port 443.... it just makes it harder for client and migration to new servers when you have onpern..
for future reference here is that i have done.
Step 1 install connectwise control see that its working.
Step 2 install IIS and Certify the web, dont forget to install https://www.iis.net/downloads/microsoft/url-rewrite
Step 3 in iis add a new url rewrite rule
Template: Blank
i named mine https redirect
input: url after path /
matches
pattern; *
Conditions
Input conditions
{HTTPS}
Match the pattern
Pattern off
Ignore case yes
input contiontons
{REQUEST_URI}
Dose Not Match the pattern
Pattern:
*.well-known/acme-challenge/*
Ignore case yes
Action Type: Redirect
Action URL/Redirect url: https://{HTTP_HOST}{REQUEST_URI}
Append Query String yes
Redirect type Found (302)
that takes care of http to https
here is the web.config iis 10
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="HTTPS redirect" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions logicalGrouping="MatchAll">
<add input="{HTTPS}" pattern="off" />
<add input="{REQUEST_URI}" pattern="*.well-known/acme-challenge/*" negate="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Change the WebServerListenUri from 8040 to 443
Why was this Declined?
We should not have to do a hacky job to get a free ssl cert and you sould not have to buy a ssl cert in 202x...
Give us a proper explenation to why this was Declined..
Agree. Just crazy. Been waiting years and years and years then poof. Declined. All of our other on-premise apps support Let's Encrypt. Let's get with it.
Yes, a good explanation is required here, this is both a simple and important request. And this security feature is long overdue.
Very disappointing.
it’s not a mistake Screenconnect was sold since then the product has gone down the pan .
software is not what it used to be everything is subscription.. it won’t be long before the masses start writing software for their own use again
We've always liked to be transparent, so we'll try to be better about adding a brief note when we close issues with a high number of votes in the future.
As a product feature, there wasn't a clean way to implement this specific ask. We discussed it multiple times and determined it wasn't a good fit. Our conversations led to improvements, like the introduction of the security toolkit which simplifies HTTP-HTTPS redirect, but a Let's Encrypt integration would have been very hard to maintain and a hack at best.
When feature requests like this come up, we tend to leave them open hoping that advances by the vendors, new tech, and sometimes team bandwidth will allow for them to be completed in the future. We perform internal check ins on most of these issues every 3 to 6 months, but sometimes issues get cut to make way for higher priorities.
Recently, we've prioritized advances in the performance of the session manager, relay, and the router to allow for better performance and scalability. We've also been looking at long time asks that will make the product more human for users, so they discover some of the power user features inside of the product. This of course is outside of the work to stay vigilant in our security posture and squash bugs.
Thank you all for your feedback, it is heard and appreciated.
Sean White
Senior Product Manager
Sean, thanks for the update, although it's certainly disappointing to have to keep hacking around this with Nginx/Stunnel. A cleaner option I've considered is putting a WAF in front of ScreenConnect, but I don't know how to get around the fact that to my knowledge, the hostname of the web interface has to be the same as the relay (which of course can't be proxied through a WAF). Does anyone know if ScreenConnect can be reconfigured to use different URLs for relay and web interface?
Jeremy, you are able to use different URI as described here:
https://docs.connectwise.com/ConnectWise_Control_Documentation/On-premises/On-premises_knowledge_base/Change_the_relay_addressable_URI
"As a product feature, there wasn't a clean way to implement this specific ask."
I don't think there was enough thought put into this ask. Let's Encrypt uses the well-documented ACME protocol.
Developers create solutions every day. Why is this any different?
I recently finished an internal project that allows our organization to obtain Let's Encrypt certificates for our internal-only private servers that do not have access to the public internet. We call it LERS (Let's Encrypt Relay Server) and it's complete with both a CLI and Web interface so that users of all skill levels can easily obtain certificates for their use.
Under the hood it uses certbot, a well established utility for managing Let's Encrypt certificates (or any other ACME-compatible CA for that matter).
This project was conceived and completed over a two month period with two developers and NO BUDGET. We now maintain the system with users in our organization all across the United States.
After this, it sounds like my next project will be creating a competing open source product that comes with Let's Encrypt capabilities built-in and we'll be selling support packages for those who require something more business friendly with SLAs.
@me if you're interested in supporting such a thing.
It really does not matter what your excuse for not doing it is. What matters is it's a feature that people want and you're not delivering. This has been really typical of all the products that have been acquired under the connectwise brand currently.
Customer support service by UserEcho
We've always liked to be transparent, so we'll try to be better about adding a brief note when we close issues with a high number of votes in the future.
As a product feature, there wasn't a clean way to implement this specific ask. We discussed it multiple times and determined it wasn't a good fit. Our conversations led to improvements, like the introduction of the security toolkit which simplifies HTTP-HTTPS redirect, but a Let's Encrypt integration would have been very hard to maintain and a hack at best.
When feature requests like this come up, we tend to leave them open hoping that advances by the vendors, new tech, and sometimes team bandwidth will allow for them to be completed in the future. We perform internal check ins on most of these issues every 3 to 6 months, but sometimes issues get cut to make way for higher priorities.
Recently, we've prioritized advances in the performance of the session manager, relay, and the router to allow for better performance and scalability. We've also been looking at long time asks that will make the product more human for users, so they discover some of the power user features inside of the product. This of course is outside of the work to stay vigilant in our security posture and squash bugs.
Thank you all for your feedback, it is heard and appreciated.
Sean White
Senior Product Manager