I have a IPv4 network behind a pfSense firewall at my small business. We have around 200 IP devices on the network. We have about 30 Axis IP cameras which have MJPG streams embedded into webpages as img tags. The webserver is internal and external facing, but we don't have a proxy for the cameras and thus only use the MJPG streams on the internal part of the network. If my provider allowed IPv6 I would use that instead and have them routable.
This worked fine for the last 10 years. Recently Chrome changed and now throws NET::ERR_CERT_AUTHORITY_INVALID errors because it doesn't like the certificates on the device from Axis Communications, I assume because they expire in 2023.
I don't understand why Google cares what my certificates are on non-routable (192.168..) IPv4 addresses?
One solution is to change a setting on each client Chrome browser to basically ignore the problem.
I took the route of trying to get a valid certificate on each device. I first looked at LetsEncrypt because of the cost, the 3 month renewal window and needing to have TXT DNS record changes for every renewal to get a domain wildcard certificate made this untenable. With the right DNS provider this would probably work, my current DNS provider does not support LetsEncrypt.
I then purchased a commercial wildcard certificate for my domain. If I upload this certificate to the IP cameras and use a FQDN instead of the internal IP address it works. I have two issues with this:
- Every 398 days I will have to upload new certificates to the cameras. If this could be automated through a script it wouldn't be too bad, but that doesn't look to be possible, in my case.
- If one device gets compromised, they all run the same certificate. This is unlikely to happen in my case, but the ideal solution would have a unique certificate for each device.
Indeed that is the direction the Axis camera management software pushes you, it runs a certificate authority (CA) that can then distribute certificates to all the cameras. Unfortunately the certificates are not valid from Chrome's point of view, these are self signed certificates. I would have to be able to sign them with the certificate I bought, but this is not allowed.
I did think this is not allowed for a very good reason, and if it was allowed the trust chain would be corrupted. But the more I think about this I can't see that as correct. I have a wildcard certificate for my domain name (example.com). Should I not "own" or be responsible for everything down from the domain I own? Or is this because certificate revocation is broken? It seems name constraints extension is the answer, but the browsers don't support it.
Solutions have been suggested, but not implemented.
In a corporate environment you distribute your own self-signed certificate and place on every employees device. If there is some way to do this easily through just a http link on our internal website, this might be a solution. I do not want to manage every device and frankly having the client have to do anything is not really a solution, it's a band-aid.
Why can't I sign certificates that are below what I own, ie xx.yy.example.com?
I can't find anywhere to purchase a certificate I can add to my CA that will then give out valid certificates from Chromes point of view. Is this correct?
It seems the standards are all written correctly, Google/Apple tighten the screws and only implement half the standard which then causes problems, is that correct?