Self-signed vs. real SSL certificate for DEVELOPMENT environment

Question

Let's say you have a web site that requires SSL and you have production server for which you have a wildcard certificate issued by Verisign or another trusted authority. You also want to run it locally on your developer's machine using SSL.

Would you use the real certificate on your developer's machine or you'd rather create a self-signed certificate instead? Why? Pros? Cons?

Personally I would create a wildcard self-signed certificate for several reasons:

• I want to have the information between the server and the browser encrypted which the self-signed certificate gives me. I do not have to prove to myself I am myself.

• If the production certificate ever gets compromised and is replaced with a new one this does not affect my developer's machine in any way.

• If I were to use the real certificate and it gets replaced by a new one it could take days before I get a copy of the new one - especially in a large organization where the developer is not the one who deals with purchasing the certificates.

• I am not sure if the real certificate comes with any restrictions - Is there a limit on how many machines it can be installed for example? If for example there is a limit of 5 computers and many developers want to used it you can exceed the limit. With the self-signed one I do not have to worry.

Are there any official "best practices" on the subject?

What are your thoughts?

Answer 1

I agree with you. The major reason, which you haven't listed, is that using the same certificate in two places requires two copies of the private key, which is an information leak and security breach.

However make sure you implement the self-signed certificate correctly, i.e. by importing it into the relevant client truststores. NOT by installing the trust-all-certificates security breach code that is often seen in answers to questions of this type.