veselov edited a comment on pull request #669: URL: https://github.com/apache/jmeter/pull/669#issuecomment-1002052031
1. Without this fix, we can't use client-side client authentication testing, i.e., there is no workaround for bug 65461 (that I could find). The API contract that `ServerAliasKeyManager` must honor as part of being a `X509KeyManager` is broken without this. Note that this actually is not about supporting multiple key types in the same store, a key store with ED25519 keys won't work either; because the key manager is "probed" for keys, so if it returns an EC key for a RSA key type request (which is what happens without the fix), the entire SSL tanks. 2. I can try adding wiremock tests. The examples at the link you gave look promising and fitting. 3. `JmeterKeyStore` is not a key store. It can be removed, as a class, but all the logic of handling alias selection is still needed, and will have to be moved to `JsseSSLManager`. I'm not sure this will be any better (but see 4) 4. Ah, are you suggesting to, instead of using a singleton SSL manager, have an SSL manager (and therefore individual key stores) for each thread? Thus eliminating the need for `JmeterKeyStore` and all the complexities dealing with a shared key store? That sounds fine to me. IDK how the multiple key stores are to be specified, .ZIP file? 5. I certainly don't mind if they were gone. A workaround to providing indices into an existing key store is always to copy the key store, leaving only the items that somebody cares about. I imagine this feature was done anticipating running multi-node tests, where each node gets a "range" of keys from the same keystore. It's more feasible to have different keystores for that scenario anyway. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
