> That is, a certificate authority like Let’s Encrypt or DigiCert will not be able to provide you with an HTTPS certificate for foo.test or 192.168.0.1 that wor

> That is, a certificate authority like Let’s Encrypt or DigiCert will not be able to provide you with an HTTPS certificate for foo.test or 192.168.0.1 that works with an out-of-the-box client like a major web browser And they shouldn't. The problem here is using a reserved and internal qualifiers for such things, not the inability[0] of public providers to provide you with such certificate. > Currently, there’s no canonical way for non-public web services to support HTTPS Depends on the definition of canonical. Easy way: just buy the cert from any provider and forget it for a year. Repeat annually. Easy way but requires automation: use a split-brain DNS setup (either full split or 'semi-split' with your internal resources under a subdomain), request a certificate for a needed FQDN (ie point A record to whatever ACME client you are familiar with), move it to the internal system. Yes, this doesn't work if your internal resources are 'https://192.168.99.9 https://192.168.99.9' and 'mysuperserver.local' (because this is a home network of Average Joe, not a even a homelab of Non-average IT Joe). Back to square one. > Various people have proposed that browsers support a special mode by which a user can enter a secret that is engraved or displayed on the device to which they want to connect This can work for a home devices, but the device (or image/text of it's shared secret) should be accessible to everyone, which means anyone can establish a secure connection now. Should it be a concern depends on the usage of such devices. BTW, WPS does exactly the same [1] But the most important aspect here lies in the last paragraph of TFA. [0] which isn't an inability but a unwillingness [1] https://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup https://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup