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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.