0

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?

  • CA often charge per installed machine for wildcard certs. I'm not sure how they'd feel about making a private key available to everyone in the world. Any MiTM attack could be mitigated by simply not using fakesite.com to explain the purpose of it,but another site where you don't give out the key. – Steve Sether Sep 9 '18 at 4:39
  • See security.stackexchange.com/questions/121163/… for several previous iterations on this theme. Also, I'm certain I've seen someone who resolves a set of 'real' (public) domains to local addresses for you and gives you the corresponding key&cert to use, but I can't now find it. Of course this has the risk that everyone else can get the key and that's all they need if they can tamper with either your DNS or routing. Although usually you shouldn't use real data in dev anyway. – dave_thompson_085 Sep 10 '18 at 7:49
2

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.

  • I think part of the pain is that I don't do it often enough to find it useful to write a tool to automate it more. Also the pain is shared when sharing code because everyone has to do it. Importing into browsers doesn't help when developing api projects, the only way I've found to do it that works is to import a certificate into my Trusted Root Certification Authorities store which I think is a bigger security risk for me. – Jason Goemaat Sep 15 '18 at 8:31
  • What I really want is a way to do that which will work in all cases, but only for a limited set of hosts. I did what you mentioned with a separate CA private key before, but it took me a while since I couldn't find good documentation for it. Using the RFC 2606 reserved domains is a great idea, I actually have a '.localhost' wildcard cert on my machine from doing those together about a year ago. If I want to do it again I'd have to try and find the scripts I used since I only did it once and that was quite a while ago. – Jason Goemaat Sep 15 '18 at 8:42
  • My particular case is having an angular-cli app talking to a .NET api and both using SSL with different hostnames, testing CORS, and wanting to give something as easy to possible to other developers to get them up and running with this recommended setup. With a cert signed by a real CA the setup would be one step: add a couple entries to your host file. The purpose of a CA is to make sure you're talking with who you think you're talking with. If the domain is 'api.invalid' and you have to have a host entry to get to it and it will only be used by developers when they know the risk... – Jason Goemaat Sep 15 '18 at 8:59

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.