In that case you don't need a certificate. Just check that the .local FQDN's IP is on a local network.
1. Look up all local interfaces' networks (IP & subnet mask)
2. Determine if .local IP is within subnet range of one of the interfaces
3. If .local IP is not on a subnet of a local interface, drop the connection
This is still "host-based networking" and there's always the possibility a rogue network could be attached to your host, such as a spoofed open access point, or an ISP with lax network security and a customer on the same subnet being attacker-controlled.
What certs prove is "this host currently has a private key and cert, and at one time this private key was used to generate a CSR for this cert, and at one time it was validated that an IP resolvable by the domain name in the CSR was also controlled by whoever issued the CSR". It's a very awkward thing that doesn't really match up to local consumer devices.
We need a vendor key registry, the way MAC address prefixes are mapped to vendors, so at least we could say "the key on this host came from vendor XYZ". The browser would need to pop up a warning saying "WARNING: You are now connected to a local device from Vendor XYZ! If you did not intend to connect to a local device, close this window!" Updates to the vendor registry could also invalidate previous entries if old keys got compromised. But this would be in combination with the aforementioned "is the site on a local network?" logic. Anyone using a .local would have to both compromise a local network and steal a key from a vendor, or be registered as a vendor, and then the user would have to be dumb enough to click through a big warning about a local device.