This was answered on the Gist in a comment[0] linking to a tweet[1]:
Things to do instead of shipping TLS certs and static private keys to consumer-grade routers you sell by the thousand:
Generate a unique keypair per device.
Use this keypair to communicate upstream, in a similar fashion to CloudFlare's Keyless SSL.
This keypair you generate on the device would need to be preloaded at the factory, unique per device, and the public key would need to be stored in a database.
When a TLS handshake comes in, you verify the entire request is signed by that keypair before signing it.
Delegated online signing for a TLS handshake isn't even in the top 10 engineering challenges for cryptography in the 2020s.
Oh, and, if you don't have connectivity to upstream and your need users to connect to configure something?
Fallback to HTTP reachable via port 80 on the private IP for the server.
[0] https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f0...
[1] https://twitter.com/CiPHPerCoder/status/1219228544548720640
Things to do instead of shipping TLS certs and static private keys to consumer-grade routers you sell by the thousand:
Generate a unique keypair per device.
Use this keypair to communicate upstream, in a similar fashion to CloudFlare's Keyless SSL.
This keypair you generate on the device would need to be preloaded at the factory, unique per device, and the public key would need to be stored in a database.
When a TLS handshake comes in, you verify the entire request is signed by that keypair before signing it.
Delegated online signing for a TLS handshake isn't even in the top 10 engineering challenges for cryptography in the 2020s.
Oh, and, if you don't have connectivity to upstream and your need users to connect to configure something?
Fallback to HTTP reachable via port 80 on the private IP for the server.
[0] https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f0...
[1] https://twitter.com/CiPHPerCoder/status/1219228544548720640