3

Is there a way to create a (self-signed) certificate that will cover all localhost IPs such as the full range for 127?

I tried both 127.* and 127.*.*.* but neither worked; I still got SSL error pages warning me that the the page (e.g., 127.2.3.4) did not match the certificate and/or was not a trusted root, despite the fact that I had made sure to close the browser, remove the old one, and install the new one each time.

There’s some webpages that show how to use wildcards in subdomains, but not IPs.

4

I assume that you are attempting to add the wildcard IP addresses as a Subject Alternate Name and not as the Subject (which doesn't allow IP addresses at all).

RFC5280 Section 4.2.1.6 states:

For IP version 4, as specified in [RFC791], the octet string MUST contain exactly four octets

which rules out wildcard certs.

Wildcards are only valid in names.

  • And even then, really only valid for CNs (Common Names), not necessarily for SANs (Subject Alternative Names). Given that an X509v3 cert can contain multiple SANs, there's no reason you couldn't generate a cert which contains an iPAddress SAN for each of the IP addresses you want to whitelist. AFAIK, there's no limit on the number of SANs in a cert. – Castaglia Apr 14 '16 at 23:04
  • SAN is 4.2.1.6 not 4. @Castaglia: 2818 describes dNSName(s) and then says "Names may contain the wildcard character ...." which (I believe) implies wildcard does apply to dNSName(s). I see many hosts using wildcard dNSName (easy example: google) and all browsers I use accept them. Also, a TLS cert chain must fit in 2^24-4 octets, so allowing for other certs and other parts of this cert SAN would be limited to about 2.8m IPv4 or 930k IPv6; whether clients actually handle this is another question. – dave_thompson_085 Apr 17 '16 at 4:27
  • @dave_thompson_085 - Thank you; I fixed it. – garethTheRed Apr 17 '16 at 7:15
  • @dave_thompson_085 RFC 6125, Section 6.4.3 indicates that clients MAY choose to honor wildcards in names. And this post argues that even CAs are split on this point. – Castaglia Apr 17 '16 at 16:15
  • @Castaglia 6125 doesn't apply to HTTPS, see 1.4. The Thawte blog link in that answer is dead, but Thawte does charge a lot (some would say gouge) for wildcard and I'd bet they don't mix because it doesn't fit their pricing model -- that doesn't mean it doesn't work. On a quick check, yahoo facebook adobe and wikipedia as well as google all have wildcard in SAN, and (from my location) serverfault superuser stackoverflow stackexchange are all actually on cloudflare with wildcard in SAN; I presume these organizations don't think they're turning away many users. – dave_thompson_085 Apr 19 '16 at 5:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.