Configure the SSLContext, SNI, keystore and truststore
By default, each virtual user will have its own
This behavior is realistic when it comes to simulating web traffic so your server has to deal with the proper number of
You can only have a shared
SSLContext if you decide to shareConnections.
By default, Gatling uses BoringSSL (Google’ fork of OpenSSL) to perform TLS. This implementation is more efficient than the JDK’s one, especially on JDK8. It’s also the only supported solution for HTTP/2 in Gatling with JDK8.
If you want to revert to using JDK’s implementation, you can set the
gatling.http.ahc.useOpenSsl property to
By default, since JDK7, JDK enables SNI by default.
This can cause TLS handshake exceptions, such as
handshake alert: unrecognized_name when server names are not properly configured on the server side.
Browsers are more loose than JDK regarding this.
If you want to disable SNI, you can set the
gatling.http.ahc.enableSni property to
Gatling supports TLSv1.3 as long as your Java version supports it as well, which means running at least 1.8.0_262. TLSv1.3 is enabled by default.
Configuring KeyStore and TrustStore
Default Gatling TrustStore is very permissive and doesn’t validate certificates, meaning that it works out of the box with self-signed certificates.
You can pass your own keystore and truststore in
perUserKeyManagerFactory can be used to set the
KeyManagerFactory for each virtual user.