I've got a question about the best practice in storing a Keystore file (
.jks) in source control. This Keystore is called by a stand-alone Java component that retrieves a private key for the purpose of signing SAML assertions.
For security purposes I would like to refrain from including this Keystore in the same git project as our Java code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our Keystore file sitting in all these locations.
That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.
I plan to place the Keystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The Keystore will be added to the stand-alone component on build as a dependency by the deployment process.
- Keystore would not be distributed with our source code
- Updates to the Keystore in source control could be locked down and carefully monitored
- Increased complexity for cert management
- Keystore will get added to the module in the deploy process anyways, so the security benefit is limited
Instead of keeping a static keystore, each time the build process is initiated a new keystore is built with a pseudo random key. The key is then added as part of the zip in our build process. Certs will then needed to be added to the keystore. Most of the instances of this Java module would have unique certificates, so not keeping the static reference would not introduce a large amount of busy work.
No static keystore for attackers to take advantage of
Each instance of the keystore has it's own password
Increase complexity of build process
If the same cert is used across multiple instances of this module the cert will have to be added to each one.
Which is my better option? Also am I going down the right path with this?