Skip to content

Todays update to 5.5.2

I am running MacOS Ventura (Intel) for my SecuritySpy server.

I am running MacOS Ventura (Apple) on my SecuritySpy Client.

I notice that now my client (trial mode) cannot get any camera images from the server now that I've upgraded with a "SSL connection error" being displayed.

Also neither the server or client updated - I just kept seeing the message "Verifying" pop up each time I loaded my client.

Is the SSL problem a bug or do I need to change something ?


  • I think I know what this could be. Version 5.5.2 is more strict about the SSL certificates it accepts when making secure connections to video devices. We made this change for two reasons: 1. security - it's always good practice to only accept certificates that are strictly valid (in date, from a trusted Certificate Authority, with matching hostname), and 2. we found that the less strict certificate parsing we were using before actually caused failed secure connections to devices that have valid certificates.

    So, as of v5.5.2, if you want an SSL connection to a video device, that device must have a strictly valid SSL certificate, and this goes for when the server providing the video stream is another copy of SecuritySpy too. When making connections over a local network, for the address of the video device you enter into the client copy of SecuritySpy at Preferences > Cameras > Device, you would generally use the server Mac's IP address or Bonjour hostname, but this now won't work for SSL connections because the hostname encoded into the certificate (which will be your DDNS name, such as won't match the address used to make the connection (the IP address or Bonjour name).

    Therefore, for connections over your local network to a SecuritySpy server, we recommend turning off SSL and using the standard HTTP/RTSP port of 8000. Or, for SSL connections, you must use your hostname (but note that this won't work for all networks as it requires a specific router called loopback, and it increases traffic on your network as the data has to then flow via the router).

    We'll consider an option (perhaps in the Advanced Device Settings panel) to allow relaxed SSL certificate parsing, but this is the situation for now.

    As for the "Verifying" message - I'm not sure what this could be - is this with v5.5.1 or 5.5.2? Could you please send me a screenshot of this? Thanks.

  • Could I trouble you for some screen dumps for SS - server and client. I want to be able to access the camera's via my mobile phone app when I am away from home in a secure manner. When I turned off "Use SSL for HTTP connections" on my client I got an error 301 message in the camera window.

  • The 301 is because the client is attempting to make an insecure connections to the server's secure port. What you'll have to do is enable the standard HTTP server on the server instance of SecuritySpy, and on the client, enter the server's HTTP port (not the HTTPS port), and turn off SSL. Over a local network, SSL isn't really required - but as I mentioned perhaps we'll add an option for relaxed certificate parsing so that you can reinstate local SSL connections in the future if you so wish.

  • I will try your suggestion tomorrow - if I need to revert back to the previous version is there a link I can use please.

  • Update: we have just released a beta version (5.5.3b1) of SecuritySpy with an option to to relax the SSL rules. You will find the new option under Preferences > Cameras > Device > Advanced Device Options > Accept invalid SSL certificates. Please confirm this works as expected, allowing you to make secure connections to your SecuritySpy server again.

  • Hi Ben - confirming beta version 5.5.3b2 solved the newly introduced SSL connection error by selecting the Advanced Device Option outlined above. Thanks for the quick response!

  • edited November 10

    I had the same problem. I am using a firewall port forwarding rule for incoming SSL connections, so I didn't want to mess with the current setup and ports. I set up the SS server to also listen on another port number using non-SSL HTTP for internal network connections. It's still relatively secure, since I don't have a firewall rule allowing incoming connections to that new HTTP non-SSL port, only internal clients can access it. If someone is on my network, the least of my problems is them viewing my cameras.

    I have a loopback rule, like you mentioned, but I try to avoid using it in order to limit overhead on the router.

    Seems like a reasonable fix to me for increased security.

  • Hi Ben, I may have spoken too soon. I'm running 5.5.1 (licensed) on my Mac Mini. When I installed 5.5.2 on my iMac (View Only mode), I ran into the SSL connection error and lost the camera views.

    Installing 5.5.3b2 (with the Advanced Device Option accepting invalid SSL) on my iMac restored the image view. However, when I then installed 5.5.3b2 on my licensed Mac Mini I lost the views on my iMac (View Only) again.

    So I reinstalled 5.5.1 on my (licensed) Mac Mini, left 5.5.3b2 on my iMac and had to reboot both Mac's to restore the image views on the iMac.

    Between my two Mac's, I may have a mismatch in the way I have the HTTP and SSL options set in the Camera Preferences. It sure would be useful to have some help screenshots of how to configure the server and client side for this new change SSL. It's getting a bit over my head. Thanks.

  • Hi @rdforbes the SSL issue described in this discussion is specifically a client issue, so if you have any problems when changing the SecuritySpy version on your server then this is a different problem. Could you please install 5.5.2 (or the latest 5.5.2 beta) on your server again, and if you see the same problem please email debug files from both client and server to us at and we'll investigate (menu option to generate a debug file: SecuritySpy > Debug > Create Debug File On Desktop). Thanks.

  • Just wanted to add to the discussion here that I had the same SSL issue with my UniFi Protect cameras after the update to 5.5.3 - the beta you posted here (I'm running 5.5.3b5) with that option for "invalid SLL" selected totally solved the problem immediately. Sincerely appreciate you providing that option so quickly because otherwise our CCTV system would have been broken. Thank you again for your excellent product support!

  • Hi @Dueport great to hear that, thanks for the feedback!

Sign In or Register to comment.