1

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. chrome://flags/#legacy-tls-enforced

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:

  1. 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.
  2. 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.

Questions:

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?

Community
  • 1
David Sindar
  • 11
  • 2
  • 80% of your question describe what you cannot do because of limitations in your setup (i.e. DNS provider which does not support Let's Encrypt, no way to automate certificate updates in your camera, no way to distribute your own CA). Yet you don't want to solve these problems. Instead you want your own restricted but publicly trusted sub-CA to issue your own certificates. – Steffen Ullrich Nov 16 '20 at 16:18
  • 1
    *"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?"* - I'm not sure what standard and what part of it you refer to. Note that the relevant conditions for publicly trusted CA and certificates are defined by the [CA/B Browser forum](https://en.wikipedia.org/wiki/CA/Browser_Forum). – Steffen Ullrich Nov 16 '20 at 16:23
  • This section would allow me to do what I want I believe: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 – David Sindar Nov 16 '20 at 18:52
  • You can buy such sub-CA and then issue the certificates you want yourself. See for example https://www.globalsign.com/en/custom-ca-private-pki or https://www.ssl.com/article/subordinate-cas-and-why-you-might-need-one/. But it does not come for free with any "normal" server certificate. Also note that for publicly trusted certificates the CA/B forum has additional restrictions than what is defined in the more general RFC 5280. – Steffen Ullrich Nov 16 '20 at 19:09
  • @SteffenUllrich That basically answers the question. You can purchase certificates from a few companies that will do this. The cost is not feasible, unless you are an enterprise. Thus when you run your own CA, you are using a self-signed certificate, unless you are one of the very few who can afford the publicly trusted certificate option. – David Sindar Nov 18 '20 at 12:03

2 Answers2

1

Here some ideas and options for your network. Hopefully, they can help you manage SSL / TLS with your cameras and devices. The options focus on your Axis cameras but may apply more broadly. However, without specific details on your network certain assumptions may not be accurate. I have no experience with pfsense firewall.

Issue #1: you can automate uploading ssl certificate to Axis cameras via sftp, scp or ftp. Axis stores the ‘in-use’ certificate in /etc/certs/web/server/http/0/server.pem. Older cameras (ie: P5512) use boa/stunnel for http/https. Newer cameras (ie: Q6115) use apache for http/https. The server.pem certificate file contains the private key (unencrypted) and certificate in pem text format. You can replace this file and the Axis camera will not know the difference. You must first have any certificate uploaded via Axis setup (self-signed works) and HTTPS configured for use and then replace the server.pem file leaving Axis https configuration alone. Axis will overwrite or delete /etc/certs/web/server/http/0/server.pem if Axis HTTPS certificate setup is changed.

NOTE: you must reboot camera or restart apache or stunnel to load the new server.pem file you upload. If the server.pem file is missing on boot, it will be generated from active certificate set through the Axis setup HTTPS page. So, if you have the private key file and certificate file for domain.com, you can manually create the server.pem from a command line $ cat domain.key domain.crt > server.pem or similar means and upload it.

Issue #2: Separate certs for each device might be a lot to manage. A wildcard cert would be best if you require different domains/sub-domains on each camera or device. Also, I am not sure wildcard compromise any risk, depending on what you mean here, if devices have unique or same certs.

Here are some options. Other options exist, but I feel these best fit your case.

Option A: Depending on how your Cameras are setup, the following option may be viable but may require changing camera http ports. If all your cameras are behind a single global IP, that may be to your benefit. As I am sure you know, Axis cameras default to port 80/443, but those are typically changed to keep unintended traffic down especially on public facing cameras.

Whatever domain you own, let us call it domain.com, you may be able to use that certificate on all your cameras and using port-forwarding with each camera having a unique port for http/https. Each camera mjpg would be accessible at https://domain.com:port/mjpg/video.mjpg. Your HTML tag would use domain.com:port (https port) and your router/firewall would forward it to the internal IP address:port. Since SSL certs are not port specific, a single certificate for domain.com (which you probably already own) would work on each camera.
I have 2 Axis cameras that I use for testing behind a router which use same certificate where the router port-forwards to each device. All requests (internal and external), ie: your tag, would use domain.com.

Option B: Albeit probably not ideal depending on bandwidth (fps and resolution) and number of concurrent views. If you have Apache server, you can use ProxyPass setup to translate insecure http mjpg to https. It sounds like your server is on-site, so this might be an option if bandwidth is not too much for server. Not ideal, but it does work, and you would not need certificate on cameras except on the web server itself at domain.com.

Also, assuming Apache server, the RewriteMap directive can help to map url to host (camera) which may help management as your web pages can use same img URL even if cameras change IP address, port, etc. If not Apache, other servers may implement similar.

Lastly, Axis Technical Support has been excellent when we have needed them.

Hopefully, this gives you some ideas. I would pursue using your domain.com certificate on all cameras (devices). If it works, maybe buy for longer term to minimize management. I also recommend testing manually before automating as there are always some surprises, but once you get a working solution, automate as needed.

If anything isn't accurate or doesn't work in your scenario, please let me know. I have quite a bit of experience with Axis Cameras, as they are complex and the state-of-SSL today has made things more difficult.

Best Wishes

stellablue
  • 11
  • 1
0

You've done a fair amount of good research here and I think you understand the problem well, but maybe I can add a bit more.

Chrome doesn't like the default A

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 would guess it's one of the following:

  1. If the CA is more than 10 years old, it may use cryptography strength that was acceptable at the time, but is no longer considered strong enough.

  2. I've noticed a trend that the CA / Browser Forum, and Chrome in particular have been tightening up on rejecting CA certificates that don't follow the X.509 Certificate spec to the letter (RFC 5280 and CA / Browser Forum Baseline Requirements). So it may be that the Axis root cert contains (or is missing) some attribute or extension that violates the spec, and Chrome has now decided to be strict about this.

Domain-specific sub-CA

I agree with you in theory, you would expect CAs to work the same way as DNS where the root authority can delegate to a domain-specific local authority.

You are correct that the X.509 Certificate spec (RFC 5280, specifically section 4.2.1.10) contains the Name Constraints mechanism which could be used to accomplish this:

The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located.

For whatever reason, this is not done. My guess:

  1. I believe Name Constraints are fairly common in the world of corporate email S/MIME certificates where one department will trust S/MIME certs issued by another department's CA, but only for email addresses in their sub-domain. I think it's less common in TLS certificates.

  2. The CA / Browser Forum puts fairly strict requirements on CAs, and harsh penalties for violating them. The way the system works now, the Root CA is ultimately responsible for any violations that their Sub-CAs commit. As an example, see this issue reported to the CA/B Forum in 2016:

Symantec issued an unconstrained sub-CA to a company called UniCredit as part of their GeoRoot program (see also Issue V). This company persistently issued certificates which were BR-noncompliant (e.g. missing SANs, missing OCSP URIs). During this time, they did not have the appropriate audits and Symantec were aware of this.

So public CAs will issue Sub-CAs to other companies, but it's really not a thing they do easily because they are taking on the liability if you break one of the Baseline Requirements.

Why not a private CA?

Finally, the obvious question; you said:

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 think you're on the right track here; certainly this is how it's usually done. Create a private CA; issue a cert for your cameras (a global wildcard cert, or one cert per device, whatever's easier); push those certs and private keys to the cameras as described in @stellablue's answer; push the CA cert to users' machines. You could host the CA cert on an HTTP page ask users to import it; but since Chrome uses the Windows cert store, you could also have IT push a powershell script that imports the cert as a trusted root.

Community
  • 1
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207