CODEWITHSUNDEEP
securityversion-controlcertificate
Anthony Mastrean
Anthony Mastrean

Reputation: 22404

Should I commit self-signed certificates to source control?

Let's say we generate a self-signed certificate for each of our customers. They're used in some part of the package/deploy pipeline and end up on the customer's local computers. They're used to connect to our web services.

Should we commit these certificates to source control? The repository is private and only accessible to coworkers. Should I leave them out for some security reason (even if that's just limiting access in case of accidental exposure, let alone malicious activity)?

If we leave them out, should we generate them as part of the package/deploy pipeline every time? Or stick them in some secure keystore and retrieve them?

Upvotes: 5

Views: 1998

Answers (1)

brantgurga
brantgurga

Reputation: 1152

This is a situation of trust and exposure. Do you trust those that have access to the repository? Bear in mind that most compromises come from insiders.

My thinking is this:

  • Don't store the deployed certificates at all. Generate them for those end systems. Sign them by a root certificate.
  • Configure your produce to trust connections made by certificates signed by that root. This way you can revoke certificates in mass if your root is compromised or selectively revoke endpoint certificates as necessary without revoking everything.
  • You can have your product reference the certificate from the system's certificate store using any public identifiers but don't store the private key.
  • Making the private key available should be a final deployment step with as minimal visibility as possible. Make it available to two or three users and use the platform's certificate management mechanisms for tying the public certificate to the private key.

Upvotes: 1

Related Questions