In earlier versions of JMeter, the client keystore relied on the system property javax.net.ssl.keyStore. This could either be set by the user prior to starting the test, or the SSL Manager Option menu item could be used to set the system property which would be picked up later.
There is also the javax.net.ssl.keyStoreType property which is normally used to determine the store type, and javax.net.ssl.keyStorePassword for the password. See http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Customization I think it would probably make sense to use these properties to directly configure the key and trust stores. So I propose to change KeyStore Config so it behaves like the SSL Manager Option dialogue, i.e. it will just save any settings as System or JMeter properties. It would make also make sense to merge it with the SSL Manager dialogue. This is currently only of use in GUI test runs - it cannot be saved with a test plan. KeyStore Config should probably be renamed as SSL Config, and would have additional fields to define the other SSL System properties. This would be entirely optional - users could define the system or JMeter properties instead - but would be more flexible as the settings would be stored in the plan, not in external file(s). The properties can be defined in the SSL Config testStarted() method as that runs before the HTTP Sampler testStarted() method. The latter can be used to preload the SSLManager if required; this would allow SSL Config to be omitted, provided that the appropriate JMeter property was set. To summarise: - keystore and truststore would be initialised based purely on System or JMeter property settings - SSL Config GUI would allow the settings to be overridden as necessary Does this all make sense?
