16

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).

Improve this question

3 Answers 3

Reset to default
12

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.

Improve this answer
1
  • 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!
    – unsafe_where_true
    Commented Jan 27, 2016 at 2:39
6

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.

Improve this answer
2
  • "You still should make sure you don't leak any proprietary information in the certificate metadata, like X.509 names of privileged entities" Could you please elaborate on this? What exactly are "X.509 names of privileged entities"? A quick web search did not help.
    – paperskilltrees
    Commented Apr 17 at 21:38
  • 1
    @paperskilltrees A certificate binds the ownership of the corresponding secret key to some entity (maybe a person name, maybe a domain name, maybe a certain enterprise). The danger I allude to is leaking a certificate claiming: "The owner of the secret key matching the public key 11:22:33:44:55:66:77 is certified to own the account [email protected]" might be considered sensitive, if it shouldn't be publicly known that "[email protected]" is a valid account name, or if it should not be known that ths account is used for some specific purpose.
    – Michael Karcher
    Commented Apr 18 at 17:21
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.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .