I wonder if the device intercepts DNS queries within the LAN for that address and substitutes in the IP of the appliance instead of 127.0.0.1. Is it often deployed as the customer premise NAT/router in addition to serving video purposes?
I'm thinking they probably wanted some other devices or browsers on the local LAN to access, via https, the appliance on the LAN. And they wanted it to have a trusted cert for that purpose. They just didn't want to have to deal with unique name and cert per device. Which, as has been pointed out repeatedly is a violation of the CA <-> subscriber agreement, because the baselines require that the CA <-> subscriber agreement forbid this. It looks to me like someone wanted to avoid the need to have a unique certificate issued for each device. The easy way forward would be for them to create a new domain, run their own dynamic DNS service for each device on that domain (get said domain on the PSL) and develop software for it to fetch and update valid certificates for these IoT devices. Presumably they could roll their own DNS infrastructure and even use something like Let's Encrypt, though I'm not certain whether Let's Encrypt is on the record as to what they'd think of such a use case. In as far as Cisco has requested a new drmlocal.cisco.com certificate.... Why? They can't use it the new certificate in the same way again (or it would just get revoked again) and the real drmlocal.cisco.com record points to 127.0.0.1, so it's not like they have a real central drmlocal.cisco.com site that needs a certificate. I think the "local" part of the name is probably most telling. They likely came up with that name because ciscodrm.local would have been impossible to get a valid cert for. Matt Hardeman _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
