AgentDVR issue: SSL
alexbn71 opened this issue · 13 comments
I own a "Business License" and I've configured "SSL Port" to 8091. I know that this can be used only on local network but it doesn't work, chrome returns "ERR_CONNECTION_CLOSED" for address https://myserver:8091
This from log:
| 21:23:32 | Listening for SSL connections on port 8091. Check troubleshooting on https://www.ispyconnect.com/userguide-agent-ssl.aspx if you are unable to access. |
|---|---|
| 21:23:32 | Accepting http connections at http://*:8090/ |
did you go through the steps to bind an SSL cert to your port?
https://www.ispyconnect.com/userguide-agent-ssl.aspx
you might need to access it via IP instead of host name
to use a host name instead check
https://www.ibm.com/support/pages/binding-ssl-certificate-server-using-server-name-or-computer-name
did you go through the steps to bind an SSL cert to your port?
SSL cert isn't mandatory I force chrome to go further
you might need to access it via IP instead of host name
Same issue with IP although I don't think this is mandatory. AgentDVR is installed on unRAID NAS and I access it through SSL and a local domain name without issues (bypassing the certificate verification on chrome). As further proof I have a docker instance of nginx on it with SSL enabled that can be accessed without problems.
The problem for now seems to be AgentDVR but I don't know how to analyze the problem since the log in this case does not help. Any suggestion?
I'noticed that config.xml has <RequireLANSSL>false</RequireLANSSL> what does means this flag?
it's unenforced, was part of ispy.
have you tried it in other browsers (firefox)? Chrome has stringent requirements on certificate encryption levels.
Tried now, same issue on firefox: PR_END_OF_FILE_ERROR.
With fireforx I can navigate the same unRAID server and the nginx instance with https and no certificate installed bypassing the certificate verification like on chrome.
I've tried a new fresh install of AgentDVR installed natively on Ubuntu (no docker) and the issue is still there. Are you sure that SSL works also on linux porting of AgentDVR?
for linux you need a reverse proxy for ssl
https://www.scaleway.com/en/docs/how-to-configure-nginx-reverse-proxy/
i haven't done that myself - only tested ssl on windows but i've heard from others that it works ok
Sorry, but something it's not clear. A reverse proxy is often used to access from outside a server in you network that does not support SSL natively. So in this case from outside you estabilish an SSL connetcion and the reverse proxy forward the request to your application via HTTP since does not support HTTPS. Is this your case?
i've heard from others that it works ok
Yes but if they use a reverse proxy your application just needs to run in HTTP ... and that's what it looks like at the moment
There is another strange thing on your help page: https://www.ispyconnect.com/userguide-agent-ssl.aspx
Bind the certificate to the IP address:port and application:
netsh http add sslcert ipport=0.0.0.0:8090 certhash=YOUR_CERT_HASH appid={642c92c9-a595-4315-b9cb-3cfdc902805b}
it's strange that you binded the certificate with the HTTP default port, isn't it?
on linux it's using the .net http listener which doesn't have native support for SSL - it does on windows
now it's clear :-) You should specify better on this page: https://www.ispyconnect.com/licensing/agent.aspx that SSL support is not natively supported on Linux as it mattered when I chose to pay for this license
https://www.ispyconnect.com/userguide-agent-ssl.aspx
SSL install on Unix (Linux/ Mac)
Setting up SSL on Unix is different to Windows. You will need to use a reverse proxy. See NGINX Reverse Proxy for an example.
it is linked to from that licensing page:
*Requires manual configuration - see SSL Configuration
You are right but "Unlocks Local HTTPS*" and use reverese proxy are no the same thing. Virtually any application that uses HTTP can offer HTTPS with the effort of setting up of a reverse proxy... not so easy, time consuming for that task and for mantaining, do you agree?
I hope you consider to give a chance to implement https natively also on linux ;-)