2

I have a stupid/crazy idea that I wanted to ask about here. It's probably not going to work, but I'm curious.

Browser security won't allow insecure web sockets (ws://) from secure (https://) pages for various reasons. I'd like to create an app that allows secure web sites to access a lot of different things via WS, and I don't want to have to create SSL certs for everything.

So...

Crazy hack: get a wildcard certificate for a domain (e.g. insecureashell.net) and set up DNS servers to serve IPs encoded in host names under that domain. So for example 1.1.1.1.insecureashell.net would resolve to 1.1.1.1.

Then distribute the private key for this wildcard cert everywhere, allowing all the apps to show up as "secure" from browsers making wss://1.1.1.1.insecureashell.net/ connections.

I'm assuming this violates some kind of cert handling policy in the https CA rules and would get this cert revoked, but I can't find anything to this effect. I also can't think of a reason this is inherently bad, since it would only apply to this specific "phony SSL" domain and nowhere else on the net. CORS headers could be used to allow or deny this, etc.

So why won't this work? :)

Edit: maybe it will. Apparently there are private SSL certs for domains that resolve to 127.0.0.1 on GitHub: https://github.com/Daplie/localhost.daplie.com-certificates

1

The specific example you use won't work, because it contains multiple levels of sub-domains, and wildcard certs are only valid for a single level. So a cert for *.insecureshell.net will work for 1.insecureshell.net, and 2.insecureshell.net, but not 1.1.insecureshell.net, and certainly not 1.1.1.1.insecureshell.net. However, that doesn't mean a variation on this can't work, at least assuming you actually control 1.1.1.1 and say, 4.3.2.1 as examples.

HTTPS and certificates don't care about the underlying IP address, they only care that the subject name or a subject alternate name in the cert match the host name of the site you're trying to connect to. For a wildcard cert, this means any single level sub-domain. So if you control those two IP addresses, and that is where you're hosting your services, you could use the following sub-domains: 1-1-1-1.insecureshell.net and 4-3-2-1.insecureshell.net to reference them. You then simply have DNS entries for those two subdomains that point at the IP addresses 1.1.1.1 and 4.3.2.1 respectively, and install your wildcare cert on both those machines. There's really no reason to do this though, generally speaking. Instead you use service1.insecureshell.net, and service2.insecureshell.net, and you have DSN entries for those names pointed at 1.1.1.1 and 4.3.2.1, and once again, install your wildcard cert on both those boxes, and you're good to go.

  • I understand and you are correct, but I was asking more about policy. Would getting a wildcard for a designated domain and then giving away the secret to make that domain https/wss accessible result in a policy violation? I suppose perhaps I should ask the issuer. The idea here is to make an app that can receive wss (secure web sockets) connections from https pages, among other things. Without a cert this is not allowed. – Adam Ierymenko Jan 31 '17 at 16:21
  • Technically an alternative might be to use Lets Encrypt, but I'm not sure it would work in this case. – Adam Ierymenko Jan 31 '17 at 16:23

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.