RTPS over TLS fails to connect to 3rd camera with self-signed crt -no cert import/trust option
Hi,
I'm trying to add a third-party IP camera (CP Plus, Aditya Infotech) to my VIGI NVR as a manual RTSP camera, and need this to work over RTSPS (RTSP over TLS) specifically for compliance with STQC encrypted-video-transmission requirements.
Setup:
- Camera: CP Plus IP camera, IP 192.168.1.230
- Camera RTSPS is confirmed working and fully verified using ffmpeg/ffplay:
rtsps://admin:<password>@192.168.1.230:443/video/live?channel=1&subtype=0
This connects successfully, completes the TLS handshake, and streams valid H.265 video (confirmed via ffplay logs).
- Camera uses a self-signed certificate (Issuer: "General", Subject: 192.168.1.230), active under HTTPS/RTSPOverTLS on the camera.
Issue:
When adding this camera to the VIGI NVR via Settings > Camera > Add Manually > RTSP, using the same RTSPS URL/port 443, the connection fails (camera does not come online / no video).
I checked the NVR's Settings > Certificate Management page, but this only shows the NVR's own server certificate with an "Export" option - there is no way to import or trust a certificate from a third-party camera.
Plain RTSP (port 554, no TLS) connects successfully with the same credentials and path, confirming the issue is specific to the TLS/certificate trust step, not the stream itself.
Questions:
1. Does the VIGI NVR support importing/trusting third-party self-signed certificates for RTSPS connections to non-VIGI cameras? If so, where is this configured?
2. Is there a different "Transfer Protocol" preset (I see "Custom RTSP Protocol1" in Manage RTSP) that handles third-party TLS certs differently?
3. Does adding the camera via ONVIF (rather than manual RTSP) handle TLS/cert trust differently?
4. Is there a firmware update path planned to support this, given STQC-driven encrypted video requirements are increasingly required for government/PSU deployments in India?
Any guidance would be appreciated, as I need to keep this stream encrypted end-to-end rather than falling back to plain RTSP.
Thanks
