Not a wildcard solution (or a particularly legit one or one a serious vendor is going to take up, but could work for DIY):
DNS poison within LAN (or proper internal DNS, or even HOSTS if DIY) for
.product.tld
Product initiates letsEncrypt for:
uid.product.tld
And posts some form of identity proof to vendor, setting up a link to carry out letsEncrypt challenges.
Verification negotiated between letsEncrypt and the vendor via public resolution of
uid.product.tld
Device completes cert process with letsEncrypt and installs cert to the device.
LAN now has TLS to uid.device.tld internally (via DNS spoof/poinon) and vendor hasn't seen the cert. (but, if not DIY, the vendor is distributing a DNS poisoner in their product)
() Caveat: I've still not set up letsEncrypt in the wild, so don't know it's limitations, but from the doc's the above looks doable.
The lack of ability to have a browser TLS to *.local without an internal CA or non-public root and the endpoint management to goes with either is a pain.
DNS poison within LAN (or proper internal DNS, or even HOSTS if DIY) for .product.tld Product initiates letsEncrypt for: uid.product.tld And posts some form of identity proof to vendor, setting up a link to carry out letsEncrypt challenges.
Verification negotiated between letsEncrypt and the vendor via public resolution of uid.product.tld
Device completes cert process with letsEncrypt and installs cert to the device.
LAN now has TLS to uid.device.tld internally (via DNS spoof/poinon) and vendor hasn't seen the cert. (but, if not DIY, the vendor is distributing a DNS poisoner in their product)
() Caveat: I've still not set up letsEncrypt in the wild, so don't know it's limitations, but from the doc's the above looks doable.
The lack of ability to have a browser TLS to *.local without an internal CA or non-public root and the endpoint management to goes with either is a pain.