On Sat, Nov 5, 2011 at 12:10 PM, sebb <[email protected]> wrote: > 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. > > Not sure I understand this part. If you're talking about the popup that asks for password when it does not find System property , I don't find it very "User friendly" and I remember being a bit confused about it when I started using JMeter with HTTPS.
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). > I agree with this if you mean SSL Config component will store: - Current options - + System properties used to configure Keystore path, password and others > > 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 > Do you mean these properties can be defined: - In System properties - In JMeter properties - IN SSL config that would override default settings > - SSL Config GUI would allow the settings to be overridden as necessary > > Does this all make sense? > I agree it's a good idea to have on Config Element in test plan to configure these properties if it's what you mean. In my opinion, we should remove the popup in SSLManager#getPassword, because it makes a different behaviour wether you are in GUI mode or NON GUI: - In GUI mode you will be asked for password so you will think your test works - In Non GUI you will have a failure -- Cordialement. Philippe Mouawad.
