Using multiple certificate in one simulation

Hello,

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 ;

session.set(“gatling.http.ssl.keyStore.file”, keystore.file)
.set(“gatling.http.ssl.keyStore.password”, keystore.password)

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.

It is unfortunately a showstopper for us ;(

Any thought about how we could achieve this ?

Regards,

Sebboh.

Hi,

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 ;

session.set(“gatling.http.ssl.keyStore.file”, keystore.file)
.set(“gatling.http.ssl.keyStore.password”, keystore.password)

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).

Regards,

Stéphane Landelle

GatlingCorp CTO
slandelle@gatling.io

Hello,

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

exec(_.set(SessionPrivateAttributes.PrivateAttributePrefix + "http.ssl.sslContexts", getSslContext))

You might want to cache the new sslContext to avoid calling getSslContext on every iteration.

It is not very nice but it is working fine so far.

Regards,

Sebboh.

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.

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 :wink:

I’ll work on a neater implementation when I have some time. I’ll submit it to you through https://github.com/gatling/gatling/issues/3671

Thanks for your work

Sebboh.

Hi Sebboh,

Thank you for implementing this feature.

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)

Edit: Thanks Stephane for implementing this feature.

Has this been implemented for the 3.3.1 or do we have to use the workaround?

It would be very useful for me. I tried to set the session values with key store but doesn’t work for me.

https://gatling.io/docs/current/http/http_protocol/#keymanagerfactory