The SSL/TLS certificates used to secure websites allow for specifying a subdomain wildcard:
*.example.com will be valid for www.example.com, subdomain.example.com etc.Is it possible to use wildcards for IP-addresses? In particular, I want an SSL-certificate for local development like this:
192.168.1.*, which would then be valid for any of the 256 different IP-addresses that are reachable inside the NAT-network of my WiFi router.Instead of just using localhost, 127.0.0.1, 0.0.0.0, ::1 as alternate names for my certificate, I also want to be able to connect my mobile phone to test the development version of my website which would be available at lets say 192.168.1.40. But then the same certificate could not be reused from a different development machine - since it would get a different IP on the same network.
Let's encrypt doesn't support using IP-addresses - which means I would instead use self-signed or locally trusted certificates instead.
No. RFC 2818 section 3.1 specifies wildcard matching for dNSName items; although it isn't clear here, this is universally implemented to allow the wildcard only as the leftmost DNS label, which is the least significant because DNS names are right-to-left. It specifies that if iPAddress is used the match must be exact (no wildcard), and even if it allowed wildcard, because IP addresses are left-to-right, only a wildcard at the right, like the one you proposed, would be useful.
However, if you're only using a /24 of 192.168.x.0 or less, as many people do, and likely only some of the addresses in that range, it's not hard to just list all the addresses you need in the cert. For example, if you're using DHCP-assigned addresses, often those cover only half or less of the range nominally available from the netmask.
No CA operating under CA/Browser forum rules, and thus acceptable to major browsers, will issue a cert for a private (RFC 1918) address; see the Baseline Requirements at https://wwww.cabforum.org . They won't do local or 'fake' domainnames like .local .localdomain .dev .test either, for the same reason.
BTW 127.0.0.1 and ::1 are real addresses, albeit not routable and thus usable only locally. 0.0.0.0 and ::0 are different; they aren't addresses at all, and you can't connect() to them; in fact they are used to represent the state of not being connected. You can use them in bind() but that actually means bind to all configured addresses (and interfaces).