Re:Sysadmins rage over Apple's 'nightmarish' SSL/TLS cert li...
by amluto on Wednesday October 16, 2024 @12:32AM
(#41855623)
Running an internal CA is maybe a good way to deal with networking hardware managed by only a few people, but it’s entirely useless if the goal is to access a device from a client that won’t trust the CA. Also, name-constrained CAs are not widely deployed, and non-name-constrained CAs are asking for trouble.
As for a proxy, how exactly would you deploy certificates, via proxy, automatically renewing, to, say, a network switch, two different brands of printer, a camera, and a pile of containers and VMs, all from different vendors? Sure, you can hack something up, but it will be a kludge and it will not scale.
Re:Sysadmins rage over Apple's 'nightmarish' SSL/TLS cert li...
by ChymeraXYZ on Wednesday October 16, 2024 @01:46AM
(#41855970)
(a) Not everyone can afford to manage that
(e) They key point is that it needs to be standardized to the point of the vendors supporting it. As long as there is a general API (for example) on the device that I can point a plug-in to, it's fine, but AFAIK such a thing does not exist at this point in time.
Re:Sysadmins rage over Apple's 'nightmarish' SSL/TLS cert li...
by fweimer on Wednesday October 16, 2024 @03:59AM
(#41856681)
Internal CAs are a pain because enrolling new CAs is difficult, especially without device management. It can also interfere quite badly with product testing.
Technically, it's not required for anyone but you to validate ownership of names further down the DNS tree once you have shown control over the DNS tree further up. Maybe combine it with the public suffix list to discourage misuse by certain service providers.
(e) also sounds a lot like just running one of the existing certbot plugins on the proxy unless the appliance can’t be reverse proxied.