Open ppalaga opened 5 months ago
It would be nice if some Vert.x/Netty expert could help me to decide which of the follwing is the case here:
VertxHttpClientHTTPConduit
that uses Vert.x HttpClient
. We perhaps miss the expected exception because we perhaps did not register a handler somewhere or we do not do it early anough? And then see only the disconnect that happens afterwards and is kinda expected too?If I'm understand correctly you do not have a keystone in the client and request one. Thus, the handshake fails. The bad certificate is not a great exception but it's a valid one. You did not send a certificate, failing the handshake.
Yes, javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
is what I get on most executions of the test and I consider it correct and expected given that the client does not send its cert.
The question is whether the fact that I am rarely getting a different exception, namely StacklessClosedChannelException
, is a problem I need to investigate or rather another legal outcome (to which I need to adapt my test)?
For the record, here it happened again: https://github.com/quarkiverse/quarkus-cxf/actions/runs/9789305617/job/27030196603?pr=1422#step:3:1210
In
MutualTlsTest.noKeystore()
a CXF client is tested that has no keystore set and therefore it is expected that the connection to a server requiring mTLS fails.However the expected exception is an exception with root cause
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
like the following.I have once spotted a different unexpected exception once on GH Actions in native mode:
This happened with the code available in this tag: https://github.com/ppalaga/quarkus-cxf/commits/i1429/