I’m currently trying to update our gatling setup from 2.3 to 3.0.3.
As I understand it is not possible to specify a jks at a vuser level anymore, doing ;
Even if it is not possible to do it at a vuser level, is it possible to specify a specific keystore at a scenario level (since each if our scenario represents a different authenticated user)
I was thinking about loading only 1 jks with multiple identities but i looks like jks aliases are not yet supported.
Indeed, this feature hasn’t been reimplemented yet when we built our new HTTP client.
It was a super ugly hack and we weren’t sure it served an actual purpose.
Even if it is not possible to do it at a vuser level, is it possible to specify a specific keystore at a scenario level (since each if our scenario represents a different authenticated user)
No, it’s not possible either.
I was thinking about loading only 1 jks with multiple identities but i looks like jks aliases are not yet supported.
I don’t think we’ll ever go with jks aliases. IMHO, jks is a kind of obsolete (java specific) format, everybody uses pem or p12 nowadays.
Any thought about how we could achieve this ?
Maybe consider sponsoring the implementation of this feature for Gatling 3.1.0, I can’t guarantee this will be a priority on our side otherwise (we’re pretty swamped).
Thanks for your answer.
Anyway I found a way to achieve this by replacing the SslContexts from the session (gatling.http.ssl.sslContexts) with another instance of SslContexts that I’ve initialized in the scenario definition.
def getSslContext(): SslContexts = {
// Retrieving the original httpConfiguration
val legacyHttpConf = configuration.http
// Creating a new SslConfiguration with the keystore I want to use for the scenario
val newSslConfiguration = SslConfiguration(
keyManagerFactory = {
val storeType = None
val storeFile = Some("mykeystore.jks")
val storePassword = "password"
val storeAlgorithm = None
storeFile.map(Ssl.newKeyManagerFactory(storeType, _, storePassword, storeAlgorithm))
},
trustManagerFactory = {
val storeType = None
val storeFile = None
val storePassword = ""
val storeAlgorithm = None
storeFile.map(Ssl.newTrustManagerFactory(storeType, _, storePassword, storeAlgorithm))
}
)
// Then instanciate a new HttpConfiguration with the new SslConfiguration
val newHttpConfig = legacyHttpConf.copy(ssl = newSslConfiguration)
// Instanciating a new SslContextsFactory based on the new configuration
val sslContextFactory = new SslContextsFactory(newHttpConfig)
// Finally retrieving the new SslContexts
sslContextFactory.newSslContexts(false)
}
Then the only thing to do is to add an exec replacing the context in the session
Indeed, this feature hasn’t been reimplemented yet when we built our new HTTP client.
It was a super ugly hack and we weren’t sure it served an actual purpose.
It did ; IMHO when you are using gatling (or any other performance testing tools) to simulate several external IS (instead of users) that communicate with the IS you are actually testing you have to be able to handle several certificates & keys.
I don’t think we’ll ever go with jks aliases. IMHO, jks is a kind of obsolete (java specific) format, everybody uses pem or p12 nowadays.
Jks is java specific yes, so what ? I still see a lot of java based project using jks.
IMHO you are wrong. It is a convenient way to manage several identities without having a shit load of file to manage. I still see a lot of jks beeing used nowadays.
All those are definitively NOT a public API. You shouldn’t be using those and most likely won’t be able to do so in future releases.
Of course, as i said, it’s just a hack.
I could argue than even a documented public api based feature usage does not guarantee the backward compatiblity
I am seeing below error when I use “.perUserKeyManagerFactory(_ => KeyManagerFactory.getInstance(“TLS”))”. How to fix this?
[ERROR] i.g.h.c.SslContextSupport$ - Can’t build perUserKeyManagerFactory: j.s.NoSuchAlgorithmException: TLS KeyManagerFactory not available
java.security.NoSuchAlgorithmException: TLS KeyManagerFactory not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
at javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:137)
