Skip to content

Invalid SSL Cert from Camera - How is Security Spy determining validity ?

Hi;

I run a fully self hosted / self managed environment for everything. This includes having my own CA for SSL/TLS and issuing all my own certs (mostly server) from that single CA.


Security Spy is complaining of invalid SSL Certs on my cameras under the following scenario:

  • Security Spy Mac Mini is the client to the cameras and the cameras are running as servers, this is of course, the basic architecture
  • Security Spy Mac Mini has my CA in both the login and system keychains in Keychain - and is trusted for all users
  • The cameras server cert is issued by the CA and correctly seen as being from the CA
  • Server cert is installed on the camera and the camera presents the server certificate in SSL/TLS handshake
  • If Safari or Chrome is used to access the camera from the same Mac mini running Security Spy, both browsers see the camera server certificate as valid, trusted, and correctly issued by my CA (basis of trust)
  • Camera server certificate has the IP address matching the IP address of the camera
  • Camera is set in Security Spy by it's IP address and not a FQDN of any kind and accessed by it's IP address
  • Access from Safari or Chrome is also by IP address and not FQDN of any kind
  • Cameras are mainly Dahua PTZs and server certs properly installed (witness Safari and Chrome)
  • Security Spy complains of invalid cert where the browsers do not
  • I did find the setting to trust invalid certs, I did tick the box, and Security Spy does then connect to the camera over SSL
  • I am, however, uncomfortable that Security Spy says it is invalid and want to know why


It seems to me that during the SSL/TLS handshake, Security Spy is inspecting some part of the camera server certificate and is unhappy with it. What might this be ?


Brendan

Comments

  • Hi Brendan,

    For making SSL connections to network devices, SecuritySpy uses Apple's CFNetwork framework, which is a standard network communications framework for use by macOS applications. It's CFNetwork that takes care of all SSL certificate validation tasks; SecuritySpy does not itself inspect/accept/reject the certificate.

    So, there must be something here that CFNetwork is rejecting, however it's going to be difficult to determine what exactly this is, because it's not our code that is doing the certificate validation. It could simply be the fact that it's a LAN IP address that's being used, which will fail a strict test (the whole purpose of SSL certificates is to validate a unique server, but LAN IPs are not unique, so should not be used in SSL certificates - this is an explicit limitation outlined in the Baseline Requirements published by the Certification Authority Browser Forum).

    I recommend that you simply set SecuritySpy to accept invalid certificates; you will still get the secure connections that you want, and there will be no security risk by doing this since LAN IPs are only accessible from within your LAN anyway, so there is no chance of making a connecting to an imposter server.

  • Ben;

    This was very helpful and gave me at least a couple of directions to go in. I will dig into CFNetwork and understand its cert validation process and tweek accordingly. I may very well find out that I do need to use an FQDN. It may also find forward dns not resolving if my camera is presenting an FQDN.


    Thanks;


    Brendan

  • Just a followup. I aligned my DNS records, "CN - Common Name" in the camera server certs, and the DNS alt and IP Addresses in the certs to be very tight. It all works now. SSL seems very tight !


    Brendan

Sign In or Register to comment.