8

I just asked the question

SSL self-signed certificates in development vs acquired cert in production?

which has promptly been answered (THANKS!).

Out of that, I have the following question:

  • Is it ok to have my self-generated and self-signed certificates in source control?

Generally I know passwords, etc. should not be in source control. But as these certs are used for development and test only, I thought there wouldn't be a problem?

The issue is that we use codeship for deployment, and there I can't run scripts to copy things around...thus the only way I see to deploy the dev certs is to have them in source control (I will need to figure out how to do it for production though, but that's a different issue).

10

Secrets -- private keys and passwords alike -- shouldn't be stored in source control. Where possible, self-signed certs should be replaced with centrally signed certs as well.

Software such as Vault facilitates distribution of secrets and most importantly rolling of them.

In this way you can setup your development machines with a level of control and stay away from the bad habit of secrets in source control because even if they are a self-signed certificate, they're still a bad habit. Things that are meant to be low value or secure unimportant things often become important later and forgotten.

Set it up right and stay with it right.

  • WoW! This is a pretty holistic approach I wasn't even aware did exist! Thank you so much. I am reading the Vault documentation now, I already understand it's a great tool, but is also pretty huge, so we will need to talk in our team about it. The main take-away for me is about Secrets and source control .Thank you! – fablife Jan 27 '16 at 2:39
2

If you are just talking about the certificate, there is no cryptographic reason to not put it under source control, as certificates are designed to be public. You still should make sure you don't leak any proprietary information in the certificate metadata, like X.509 names of privileged entities.

If you think about also storing the secret key in the repository, it is just like storing a password. So in fact you created a shared "account" between all users that have access to the repository or a working copy, so all problems of shared accounts apply. The security implications depend on what the possessor of the secret key may do. If that certificate allows login into some production systems, you are doomed, while on the other extreme, if the only use for the key and certificate is in testing your product, and it is not accepted anywhere else, no harm is done. In the latter case, you might consider generating the certificate during test on the fly. There are valid points for both using a fixed test certificate/key and generating them on the fly, but this discussion is no longer related to IT security, but to source code and build management.

0

Speaking from experience, it's commonplace to have self-signed certificates for your local machine(s) address in order to test TLS/SSL before making the investment of buying a certificate. You'll have to manually insert the certificate into the browser you'll be using to test the website if you're talking about a website connection.

I would still not publish your server private key into source control if it's accessible to the public, but as long as the certificate private key is different from the one being deployed I don't see much harm as generating new self-signed certificates is an easy procedure.

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.