SSL routines:OPENSSL_internal:KEY_USAGE_BIT_INCORRECT when simulating API using target domain

I have a strange situation, when simulating on target domain (which is different than direct microservice address):

  • I have recorded some activity to HAX file (proxy mode is impossible in my case, as it is managed by company, and turned off by default)
  • I have run the simulation and I obtained the following problem:
18:46:16.152 [TRACE] i.g.h.e.r.DefaultStatsProcessor - 
Get transaction ID: KO i.n.h.s.ReferenceCountedOpenSslEngine$OpenSslHandshakeException: error:1000012e:SSL routines:OPENSSL_internal:KEY_USAGE_BIT_INCORRECT
Session(Site Stress Test,3,Map(gatling.http.ssl.sslContexts -> io.gatling.http.util.SslContexts@6f39d99e, gatling.http.cache.dns -> io.gatling.http.resolver.ShufflingNameResolver@2e302c0, gatling.http.cache.baseUrl ->,KO,List(),io.gatling.core.protocol.ProtocolComponentsRegistry$$Lambda$611/0x00000008010ef5b0@e78a328,
HTTP request:
	accept: */*
	accept-encoding: gzip, deflate, br
	accept-language: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7
	user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36
HTTP response:
18:46:16.152 [TRACE] i.g.h.e.r.DefaultStatsProcessor -

If I change the baseUrl from to https://direct.cluster.base.url (imagine some strange cloud cluster address), then everything works just fine. Since error message strongly suggests problem with SSL, what I did next is:

  • exported *.crt file from my target domain using Chrome browser
  • created a keystore and added *.crt file to it
  • added keystore data to ‘gatling.conf’ file

Still nothing. Or the same actually. I tried both ways (using both addresses) in Postman, and worked OK. I checked the problem I suffer in web search engine and it does not seem deeply described. Did Anybody here faced that?? Appreciate any help. Thanks in advance.
Cheers, Arek

Maybe check OPENSSL_internal:KEY_USAGE_BIT_INCORRECT after update to · Issue #19262 · ClickHouse/ClickHouse · GitHub.
It points to BoringSSL being more strict than other TLS implementations for security reasons and rejecting some malformed certificates where the keyUsage extension is not set.