Actually, in industrial environments that seems like the perfect choice.

Over 30 years, you'll find vulnerabilities in pretty much anything; so you don't want that device on an open network anyway. But, you can put it on an isolated VLAN, configure it so that it's accessible only by that proxy and no other computers, and then all the http traffic is in the isolated part, and the users access the proxy through https.

This sounds like the sanest solution so far, but this would require a push to get these additional gateways installed in our customers' IT.

I'll be honest, I've never set up the thing I mentioned, but it sounds vastly less error-prone than writing some certificate update support (likely written in C/C++) that writes the certificate bytes directly to the devices.

Initial can-of-worm questions are "who's allowed to update the cert?", "how does the device authenticate the person updating it?", "what's the failure mode if an update goes wrong?", "how long shall we test the new cert-writing-module?", "will the customer even bother after the initial certs expire we install for them and instead just tell their users to flip the Chrome flag?", "how do we also update TLS and crypto libraries to support future certs or standards?"