繁体   English   中英

加特林中的 SSL 签名证书身份验证

[英]SSL signed certificate Authentication in Gatling

我需要与需要 CA 签名证书的服务交谈。 我在自己的用户名上有证书,并且在服务器端导入了相同的证书。因此,当我发送请求时,我将生成我的证书用于服务器的身份验证,服务器与这些证书匹配并将响应发回。

当我在浏览器中请求 URL 时,它会自动选择/询问(在弹出窗口中)我的用户名上的证书,当我选择该用户名时,请求会以正确的响应加载。

现在我想在 Gatling 中模拟同样的事情。 但是在加特林中,我收到了 401(未经授权)。

我在服务器端验证,当我从浏览器发送请求时,我可以看到证书正在通过,但是当我从 Gatling 发送请求时,证书没有与身份验证请求一起发送。 在服务器端,它说没有找到证书。

我已将我的用户名 CA 签名证书导入 JDK 密钥库并发送请求,如下所示。

def execute(): ScenarioBuilder = {
val parameters = Map("$filter" -> "${Id}")
val positionsScenario: ScenarioBuilder = scenario("Locations")
  .feed(accountFeed)
  .exec(requestHandler.getSAPRequest("Locations", parameters))
positionsScenario
}

def getRequest(requestName: String, parameters: Map[String, String]): ChainBuilder = {
val messageBuilder = exec(http(requestName)
  .get(s"$uri")
  .queryParamMap(parameters)
  .check(status.is(200))
)
messageBuilder
}

我已经使用 system.property 配置了我的证书,因为 gatling.conf 没有在场景中发送证书。

    System.setProperty("gatling.http.ssl.trustStore.file", "C:/Program Files/Java/jdk1.8.0_111/jre/lib/security/cacerts")
    System.setProperty("gatling.http.ssl.trustStore.password", "changeit")
    System.setProperty("gatling.http.ssl.trustStore.type", "JKS")

    System.setProperty("gatling.http.ssl.keyStore.file", "C:/Program Files/Java/jdk1.8.0_111/jre/lib/security/vikram")
    System.setProperty("gatling.http.ssl.keyStore.password", "changeit")
    System.setProperty("gatling.http.ssl.keyStore.type", "JKS")

这是来自加特林的日志

    Session(SAPPositions,4,Map(gatling.http.ssl.keyStore.password -> changeit, 
    gatling.http.cache.dns -> io.gatling.http.resolver.ShuffleJdkNameResolver@6e027c67, 
    gatling.http.ssl.trustStore.type -> JKS, gatling.http.ssl.trustStore.password -> changeit, 
    accountId -> (account_id eq '000194878-182182-AU-AUD'), 
    gatling.http.ssl.keyStore.file -> C:/Program Files/Java/jdk1.8.0_111/jre/lib/security/vikram, 
    gatling.http.ssl.keyStore.type -> JKS, gatling.http.referer -> https://d3u.internal.com/sap/op/data/ACCOUNT_LOCATION_API_SRV/locationapi?%24filter=%28account_id%20eq%20%27000194878, 
    gatling.http.ssl.trustStore.file -> C:/Program Files/Java/jdk1.8.0_111/jre/lib/security/cacerts, 
    gatling.http.cookies -> CookieJar(Map(CookieKey(sap-usercontext,d3u.internal.com,/) -> StoredCookie(sap-usercontext=sap-client=100; path=/,true,false,1517797866679))))
 1517797866640,0,KO,List(),io.gatling.core.protocol.ProtocolComponentsRegistry$$Lambda$458/906347731@1443b002)
=========================
HTTP request:
GET https://d3u.internal.com/sap/op/data/ACCOUNT_LOCATION_API_SRV/locationapi?%24filter=%28account_id%20eq%20%27000194878
headers=
Connection: Keep-Alive
Accept: */*
Accept-Encoding: gzip, deflate
Host: d3u.internal.com
=========================
HTTP response:
status=
401 Unauthorized
headers= 
set-cookie: sap-usercontext=sap-client=100; path=/
content-type: text/html; charset=utf-8
sap-system: D3U
www-authenticate: Basic realm="SAP NetWeaver Application Server [D3U/100]"
Transfer-Encoding: chunked
Content-Encoding: gzip

这是我的服务器端日志:

[Thr 139749210060544]   Server-configured Ciphersuites: "TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES256_GCM_SHA384:T
[Thr 139749210060544] Mon Feb  5 11:09:34 2018
[Thr 139749210060544]   Client-offered Ciphersuites: "TLS_RSA_WITH_AES256_CBC_SHA:TLS_RSA_WITH_AES128_CBC_SHA:TLS_RSA_WITH_RC4_128_S
[Thr 139749210060544]   No Client Certificate
[Thr 139749210060544]   New session (TLSv1.2, TLS_RSA_WITH_AES128_CBC_SHA)
[Thr 139749210060544]   HexDump of new SSL session ID { &buf= 7f19c001306c, buf_len= 32 }
[Thr 139749210060544]    00000: 3e 2d 9e fb b6 f3 bf 63  fb 49 27 75 f3 d8 24 c7   >-.....c .I'u..$.
[Thr 139749210060544]    00010: 90 85 bb ed 5e 39 d6 cc  15 27 25 04 fe 29 44 3f   ....^9.. .'%..)D?
[Thr 139749210060544]   SapSSLISessionStartFin(sssl_hdl=7f19c0016b50)==SAP_O_K
[Thr 139749210060544]  in/out: status = "new SSL session,TLSv1.2,TLS_RSA_WITH_AES128_CBC_SHA, **NO client cert"**
[Thr 139749210060544] <<- SapSSLSessionStartNB(sssl_hdl=7f19c0016b50)==SAP_O_K
[Thr 139749210060544] HttpParseRequestHeader: no content length set
[Thr 139749210060544] HttpParseRequestHeader: no transfer-encoding set
[Thr 139749210060544] HttpParseRequestHeader: Version: 1001
[Thr 139749210060544] HttpParseRequestHeader: Keep-Alive: 0
[Thr 139749210060544] HttpParseRequestHeader: no server port set
[Thr 139749210060544] HTTP request (raw) [5/540445/1]:
[Thr 139749210060544]   GET /sap/bc/gui/sap/its/webgui?sap-client=000 HTTP/1.1
[Thr 139749210060544]   host: d3u.internal.com
[Thr 139749210060544]   connection: Close
[Thr 139749210060544] Connection Info: role=Server, local=vd3u01.internal.com:44300, peer=10.137.249.2, protocol=HTTPS
[Thr 139749210060544] ->> SapSSLGetPeerInfo(sssl_hdl=7f19c0016b50, &cert=7f19e605e990, &cert_len=7f19e605e99c,
[Thr 139749210060544]    &subject_dn=7f19e605e988, &issuer_dn=7f19e605e978, &cipher=7f19e605e980)
[Thr 139749210060544] <<- SapSSLGetPeerInfo(sssl_hdl=7f19c0016b50)==SAP_O_K
[Thr 139749210060544]     out: cert_len = <no cert>
[Thr 139749210060544]     out: cipher   = "TLS_RSA_WITH_AES128_CBC_SHA"

在服务器端日志中,它说未发送客户端证书。 我怀疑我在请求或我的代码本身中发送了错误。

谢谢

我想出了什么问题。 我生成的证书不是向服务器进行身份验证的有效证书。

我如何知道它们是否有效/无效?

刚刚使用下面的行启用了java调试

System.setProperty("javax.net.debug", "all")并在 gatling 最初启动时查看调试行。 我看到一切都是空的,这对我来说是可疑的。

keyStore is : C:/Program Files/Java/jdk1.8.0_111/jre/lib/security/vthaduri
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: C:\Program Files\Java\jdk1.8.0_111\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is : 

使用 javax.net.ssl [仅供调试]

此外,我使用javax.net.ssl而不是gatling.http.ssl来设置信任库和密钥库。

最后.disableClientSharing

val httpBuilder: HttpProtocolBuilder = http
      .disableClientSharing
      .baseURL(AppConfig.getRuntimeConfig("endpoints." + environment + ".sap"))
      .connectionHeader("Keep-Alive")
      .acceptHeader("*/*")
      .acceptEncodingHeader("gzip, deflate")

后来我按照 galting 正确配置了所有内容。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM