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.
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
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.
"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.
100% this. I cannot believe this was declined.
"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.
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?
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
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
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.
Partner would like SC product supported LetsEncrypt on Windows or Linux.