What problem would there be with an open private key for developers to use?

Question

I always find it a pain to create a new key for development and I was thinking of doing something like this both for myself and to help other developers out:

1. Register a domain like fakesite.com
2. Get a wildcard ssl certificate
3. Make both the certificate and private key files available to the public
4. Test my sites locally by adding entries to my host files for whatever I want to test (i.e. api.fakesite.com, www.fakesite.com, etc.) either pointing to 127.0.0.1 or to my ip on my local network and using the publicly available certificate and private key.

fakesite.com would send all subdomains to one page on the main website which would explain what it was for. The actual certificate and private key would be made available elsewhere such as in a github repository.

The only problems I could think of would be

1) Attacker can perform a MITM attack rerouting your DNS to their website, which they can make look secure by using the publicly available 'private key', and trick you into browsing to a web page like 'citibank.fakesite.com' and entering your information.

2) As a developer I mistype a url and sent traffic to apu.fakesite.com, which is being used like above so they can capture the traffic I was meaning to send to my local computer

It actually seems more secure for me as a developer than creating a self-signed certificate using publicly available tools and having the key sitting around on my hard drive for my tools to use. If anyone got that, they could spoof any website for me because I have to trust it, right?

By using someplace like letsencrypt for the authority, they can say my certificate/key is only valid for that one domain, which should only be used for local testing and development.

Are there issues I'm not thinking about, or is #1 likely enough that this would be a bad idea?

Answer 1

I have the feeling that you are trying to tackle the problem you have from the wrong end:

I always find it a pain to create a new key for development ...

I'm not sure what you are doing which causes so much pain, but if you are doing the same steps again and again it might be actually useful to find a way to automate these steps for yourself.

It actually seems more secure for me as a developer than creating a self-signed certificate using publicly available tools and having the key sitting around on my hard drive for my tools to use. If anyone got that, they could spoof any website for me because I have to trust it, right?

If I interpret this correctly you are creating a self-signed server certificate with basic constraints CA true (i.e. this certificate can be used to issue certificates). It is correct that this can be used to create more certificate and thus access to the certificate and its key can be used to man-in-the-middle all sites - provided that you've imported this certificate as trusted CA (certificate authority) instead of a trusted server certificate. Note that just adding an exception once the browser complains will not add this certificate as certificate authority.

It also would mean that the attacker needs to have access to your system in the first place - in which case it might do even more harm. Nevertheless, this particular problem can be easily mitigated:

• Most (all?) browsers actually can import a self-signed server certificate which has basic constraints CA false. There are though tools which cannot deal with this and expect CA true on a self-signed certificate.
• One could create a CA with its own private key, let it issue some leaf certificates (basic constraints CA false) with another private key and then throw the private key of the CA away. The CA can still be imported as trusted into the browser so that all certificates issued by this CA will be trusted too. Since the private key of the CA is deleted one cannot create more certificates though.

fakesite.com would send all subdomains to one page on the main website which would explain what it was for. The actual certificate and private key would be made available elsewhere such as in a github repository.

It is not a good idea to use a publicly available domain for this. The problem is that it is insecure by default, i.e. the browser will resolve the domain and try to connect to it and man in the middle attacks to the domain will not be detected since everybody knows the private key to mount invisible attacks. And then the attacker could do the attacks you've already described and maybe more.

Fortunately the public CA which has issued the certificate would revoke the certificate anyway if the private key gets known publicly and thus this idea would not work (provided that the browsers check for revocation - which many don't or don't do properly).

But the general idea could be modified to be safer. If one simply uses a domain which will never exist publicly, a browser can only connect to the domain if the system is specifically setup for this. RFC 2606 defines some top level domains which might be used for this, i.e. .example, .test, .invalid and .localhost. When using any of these top level domains an attacker could only harm developer systems which are specifically setup to resolve such domains and which have explicitly imported this certificate as a trusted server certificate, instead of being able to harm arbitrary systems.