What are the risks of trusting a self-signed certificate on a development machine?

We have development machines that test web applications under development over https, because the deployed app operates over https.

We have a couple of internal url's set up in our hosts file, so that https://project-dev and https://project-www can be used to test different branches. We also debug in the windows azure dev fabric, which causes the app to go over https://127.0.0.1. There is another cert for this, however it is automatically generated by the dev fabric.

To make our browsers ignore the unsafe certificates, we drag them from Personal to Trusted Root Certification Authorities.

Does this make our dev machines vulnerable in any way? If so, how?

Solution 1:

The only difference between a CA signed cert and a self-signed cert is that your browser (or other ssl client) does not implicitly trust the self-signed cert. If you trust the cert, importing it so that your client doesn't warn is no different from the browser writer importing the ca certs into their keystores.

Solution 2:

Potentially, if your certificate private key gets out it could allow someone to MITM you.

Conclusion: Not really.

There's always a little risk, but you're a couple developers that someone would have to explicitly target in order for that to happen.

Perhaps there's something I'm not thinking of, but somehow I think you'll make it.

Solution 3:

A self signed certificate is not more vulnerable that one signed by a certificate authority. It becomes insecure because of the behavior of the users, that will get use to accept and trust them blindly. If you add a certificate to Trusted Root Certificate Authorities, then any certificate signed by that certificate will be trusted by your machine. So if one of your selfsigned certificates gets compromised, than all the machines where it is installed become vulnerable to man in the middle attack. The worst is that you can not have a revocation list for them and you have to remove them manually in case it get compromised.

The best approach is to use an internal certificate authority and sing ALL internal certificates with your CA. This is both very secure, convenient and cheap.

To setup a CA:

1. Build a physical machine that will be used as CA. Only trusted administrators must have access to this box (2 persons ideally).
2. Create a Revocation server, this should be different from the CA machine. (server with the list of revoked certificates, that will be accessible at least across your organization)
3. Crate a root certificate.
4. Create an intermediate certificate that will be used for signing purposes.
5. Print the root CA private key on a paper and lock the paper in a secure safety box.
6. Destroy the CA root private key from the CA server.
7. Distribute the CA certificate in the whole company and install it as a trusted CA.
8. Distribute the CA intermediate certificate and install it as an intermediate CA (not trusted).
9. Sign all certificates with the CA intermediate certificate. Do not allow expiration dates more than 1-2 years. Do not allow asymmetric keys less than 2048.
10. Add to revocation list all compromised certificates.