Getting and then distributing a wildcard SSL certificate -- is this okay?

Question

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

Answer 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.

Answer 2

I am using the setup you described in several projects and it has been working fine for a few years now. I'm using a bit of a different format though: ws1-1-1-1.example.com. Like Xander said, service1.example.com would be better, but since my servers automatically get created and assigned a random ip, this would cause issues with DNS caching.

This is fine regarding policy as far as I know. I'm using Let's Encrypt, at the moment their Subscriber Agreement states:

You agree that at all times You will take, all appropriate, reasonable, and necessary steps to maintain control of, secure, properly protect and keep secret and confidential the Private Key corresponding to the Public Key in Your Certificate (and any associated activation data or device, e.g. password or token).

So, as long as you distribute the certificates in a safe way to all your servers this should be ok.