0

I would like to have an SSL cert for *. That is, for any domain whatsoever. The idea is to sign it with a custom CA cert, install that CA cert on a target device, and use that device to connect to ip-based addresses (e.g. https://192.168.1.123). There's no DNS available, and the address may be different each time. The browser on the target device should work without warnings, but only as long as the wildcard cert presented is signed by the known CA (which is our custom CA the cert of which was installed on the device), to prevent any possible MITM attacks.

Would browsers understand such a wildcard cert? Is there any other workaround possible to allow using browsers to connect to arbitrary IP-based SSL servers without warning and with MITM protection at the same time (assuming that it's possible to customize the client list of CAs)?

dragonroot
  • 5,653
  • 3
  • 38
  • 63

3 Answers3

1

There are two specifications about certificate identity validations for HTTPS: RFC 2818 (the HTTPS specification itself) Section 3.1 and RFC 6125 (a more recent RFC trying to harmonise how this is done for any protocol).

As far as I can interpret RFC 2818, it doesn't forbid it (although I guess it doesn't consider the use case at all):

Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.

RFC 6125 generally discourages the use of wildcard certificate altogether (section 7.2) and only allows it in principle in the left-most label (section 6.4.3). This more or less implies that there should be more than one label.

There is an additional errata for RFC 6125 on the subject: "RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier":

Note also that this issue begs the question of being able to determine what constitutes a so-called domain name "public suffix" (e.g. ".com", ".co.uk") -- we can't simply write into the spec "the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position".

Specifications aside, this is unlikely to work in practice. No commercial CA should ever issue one of those. They make mistakes once in a while perhaps, but hopefully nothing so foolish. You might be able to achieve this by deploying your own CA (or perhaps with a local automated CA within a MITM proxy you'd approve). Even if this was the case, some clients will simply refuse to validate such certificates. For example, Chromium even forbids *.com or *.co.uk.

Note that in both cases, wildcards are for DNS names, not IP addresses. Having a certificate for * as you would like wouldn't work for your use-case anyway. Perhaps looking into alternative DNS solutions (e.g. mDNS) to be able to use a name might help.

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
0

Yes there are wild card certs. You may please check with SSL cert provider to get more details .I doubt if this can be based on IP

Amitkumar Singh
  • 1
  • 1
0

While the public key infrastructure is broken, it is not that broken that you will get an certificate for * and the browser will accept it. The relevant RFC is RFC2818 and if you read it you'll see that the browser accept *.example.com and www*.example.com, but not www.*.example.com, www.*.com or even *.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172