note, these values are actually commented out and the user is free to set these to whatever you want (so you can use conf/ if you so choose). However, that said, we should make these commented out locations say "conf" since that is probably the better of the two places to put them (the other being data/) since it is true that anytime someone does a --cleanconfig or otherwise purges the data/ directory, those certs will go away (which is probably not the desired thing to happen).

Note that the agent auto-update will attempt to retain security certs that are found in either data or conf directory with the name matching the regexes "*keystore*" or "*truststore*" - so if you change this to conf/ in your agent config, agent auto-updating will still work.

I noticed in our RHQ docs, we already talk about this:

https://docs.jboss.org/author/display/RHQ/Securing+Communications#SecuringCommunications-Step3DistributeYourKeystoresandTruststores

"RHQ Agent Instructions

Each RHQ Agent distribution has a /conf directory. It is the logical choice to store the agent's keystore/truststore files. (note: putting them here makes them safe when performing agent auto-updates - agents will retain all keystore/truststore files that are found in the /conf and /data directory). For each RHQ Agent, take its keystore file (make sure the keystore file has the appropriate CN value that matches the RHQ Agent's hostname) and store it in the agent's /conf directory. Make a copy of your truststore file and place it in the agent's /conf directory as well."

git commit to master: 58e3a41

I am not sure this is actually being resolved by the commit. The default still seems to be the data directory. As such, a --cleanconfig will result in the loss of the keystore/truststore. 

The expectation is that one of the following occur:

1.  By default, no certificates are stored in the data directory and instead the conf directory is used and documented. Our recommendation should be not to store any non-volatile data in the data directory.

2.  The purge data directory methods also utilize the same exclusion regex that the upgrade uses to prevent files containing truststore and keystore in their name from being removed.

After looking at the code more closely, the easiest and less-intrusive/less-risky fix for this would be to explicitly set the keystore/truststore preference settings at agent startup time (prior to initializing the comm layer) to a default location (the conf/ directory).

I'm running the unit tests to make sure this fix plays nice with them.

git commit to master: 80e9f52

to test:

0) install and run RHQ Server - leave all defaults (specifically, https port of 7443)
1) install a clean agent (never registered before, new installation)
2) edit agent-configuration.xml and set these:

    <entry key="rhq.agent.server.transport" value="sslservlet" />
    <entry key="rhq.agent.server.bind-port" value="7443" />
...
    <entry key="rhq.communications.connector.transport" value="sslsocket" />

3) run the agent, accept all defaults and make sure it registers to server and everything is OK
4) look in the agent's conf/ directory and see that it auto-generated the keystore there.

Another way you can test is to simply set up agent secure communications, putting the keystore and truststore in the default location (conf/keystore.dat, conf/truststore.dat), do NOT set the keystore/truststore prefs in agent-configuration.xml and see that the agent can find them in the conf/ directory and everything works.

Mazz,this is product bug which should go to MODIFIED first

Mazz, can you provide test steps around upgrades too.

(In reply to comment #8)
> Mazz, can you provide test steps around upgrades too.

The only thing you would do to test upgrades is to simply install a new agent using the agent update binary and see that the original certificates are preserved in the new agent.

So, once you configure the agent to put their stores in conf/, it should remain in conf/ even after an upgrade.

I think, however, what you are asking is what happens to old agents (of versions prior to this fix) when you upgrade them to the new agent where the default is now conf/? The old agent had to key/truststores in data/ - where do they go in the new agent?

I think I need to test this. I have a feeling this might break. The old keystore/truststores will remain in data/, but since the user probably didn't explicitly set the configuration settings, the default will switch to conf/ - the agent will look in conf/ see they are missing and bomb out.

I'm going to re-open this, test this scenario and fix it (I assume it is broken, based on how I think things will work).

this definitely won't work. When I ran my test, as expected, the data/keystore.dat did get copied to the new agent's data directory, but now we don't look there by default. since the setting wasn't explicitly set, the new agent will use conf/ as teh default, and I see this because it auto-generated a self-signed cert and put it in a keystore in conf/.

We need to somehow know that we should move the keystore/truststore files from the data/ dir to the conf/ dir when we upgrade.

git commit to master: ac38cd8

when the agent is upgraded, the preferences are set appropriately and the keystore/truststore files (if they exist) are moved from the data/ to the conf/ directory.

To test you just set up secure communications with an older version of RHQ, then upgrade to the new agent and check to see that your data/keystore.dat and data/truststore.dat files moved from data/ directory to conf/ directory. You can also look at the agent's preferences (via getconfig) to see the four settings pointing to keystore/truststore files are now set and pointing to the files in the conf/ directory.

As this is MODIFIED or ON_QA, setting milestone to ER1.

Created attachment 828755 [details]
keystore-dir

jon jon 3.2 keystore by default is being stored in rhq-agent/conf/ directory during the install and upgrade (in <= 3.1.2 it was stored in rhq-agent/data/ dir)

screen-shot attached show the stored keystore for agent in old and upgraded versions