ProHD No Video using HTTPS

[vegas50000]

Same issue here, new firmware implements third-party SSL cert support, which I tested and works great. But you still can't view the video stream remotely over HTTPS. What a joke...

[PsychoPhreak]

I'm not sure what issues you guys are having. Did you factory reset after upgrading?

I generated my certificate, it installed happily, and I'm able to view video remotely without issue over https, so yes I am finally decently happy with Amcrest and have it finally working to my expectations.

To note, this is on model IP2M-841, are you both having issues with the IPM-721? I'm wondering if there's a bigger hardware/memory difference between those models than just 1080 support.

[vegas50000]

Multiple factory resets of IP2M-841 does nothing. Remote HTTPS still doesn't work. Shitty programming is causing this.

[sz1]

I finally managed to connect with https from outside the lan:
You need to forward also the http port (to the ip cam http port). It kind of awkward. I want to use only SSL and leave the http port closed....

another problem is that the android app uses only non-encrypted communication...

the ip cam is very nice but unless it is properly secured, it is not ready for the serious market...

[PsychoPhreak]

Yes, the video stream itself goes over the RTSP http port that needs to be forwarded as well obviously. This does not make the camera any less secure as it's only used for the video streaming once authentication has passed over the https port. You do NOT need to forward the non RTSP http port (80 or whatever you used)

The https port is used for authentication & command/control items (PTZ, audio on/off, etc) that way your authentication information does remain secure.

I do not use the Amcrest App on mobile so I was unaware you can't force SSL communication over it. I use Tiny Cam Pro and it allows connection through HTTPS as well without issue.

[sz1]

Yes, the video stream itself goes over the RTSP http port that needs to be forwarded as well obviously. This does not make the camera any less secure as it's only used for the video streaming once authentication has passed over the https port. You do NOT need to forward the non RTSP http port (80 or whatever you used)

The https port is used for authentication & command/control items (PTZ, audio on/off, etc) that way your authentication information does remain secure.

I do not use the Amcrest App on mobile so I was unaware you can't force SSL communication over it. I use Tiny Cam Pro and it allows connection through HTTPS as well without issue.

When you connect from a browser the http port has to be open (the https+rtsp are not sufficient). I was using the android ip cam pro and it worked there only via http. the Amcrest app works only via the unsecured tcp port. I tried Tiny cam pro and it does work as you said via the rtsp+https (without the tcp and the http)! now, for $4 I can put the cam for use (even though it is not a complete solution... thank you.

[sz1]

PsychoPhreak - I take the above back. It seems like you are wrong. Remove the https port forwarding and you will see that Tiny Cam Pro will authenticate on the unsecured RTSP. The only difference is that you can't control the camera.

Bottom line - Amcrest 841 is an unsecured cam = Not usable for anyone who cares about privacy.

[Madelinot]

I'm having the same issue on IP3M-941. HTTP works fine. I use NGINX to proxy encrypted traffic from 443 to port 80 on the camera. The page says that there are not enough available resources when I try to play the live stream while trying to remote view using ssl.

So, two years later and still no fix for this basic issue? WOW! I was hoping this would be much better than my old Foscams. I will be returning the camera...

[Madelinot]

I was finally able to make some progress. Here is my setup right now and how it works:
- IP3M-941 connected to 5g WIFI (I will connect to cable soon for better performance)
- NGINX installed on a Raspberry Pi, with valid SSL certificates (and my own domain name of course)
- One domain name and one certificate per camera. NGINX Proxy takes care of redirecting traffic to the right camera based on the domain name.
- Self-signed certificate on the cameras using the interface provided, although they are probably not used (I didn't try without)
- I opened all other ports one-to-one on my router (TCP, UDP and RTSP); from my router to the camera directly, not through NGINX
- From the internet, I use HTTPS. It gets to NGINX and traffic gets forwarded to HTTP locally on my network.

Everything works for the most part, albeit a little slow. I also ditched Amcrest own iOS app in favour of Live Cams Pro, which is much better and supports SSL. That app also support my old Foscams, which is a bonus.

I'm still testing and configuring, but things are better than they were. It doesn't have to be this complicated, it's really poor design and programming from Amcrest.

Later

[Madelinot]

I'm finally done I think. Like I said, the only thing I had to open to the internet are HTTPS port 443 and RTSP port. On my router, port 443 is forwarded to NGINX 443 which proxies traffic to the HTTP port of the camera based on specific domain names. That way, I can use a different domain name and individual certificate for each cameras; they each have their own secure URL. For RTSP, each camera has a different port and I configured my router to forward traffic directly to the same port from the internet directly to the camera (first camera port has 554, second camera has 555, third has 556, etc.). I'm not forwarding TCP and UDP ports.

Works well so far. And all secure....