VertxHttpClientHTTPConduit does not honor default Java truststore
#1665
Comments
jcjveraa
changed the title
|
Sounds like #1646 |
|
Feel free to reopen if you feel this is not a duplicate of #1646 |
|
Thanks for the quick response, I failed to check the known issues as I
assumed I was doing something wrong :-/
My organisation's local maven repository was missing some transitive
dependencies for 3.17.4, which was the only reason for trying 3.16 rather
than going to 3.17 directly. Will try your suggestion tomorrow.
Op ma 16 dec 2024 om 14:39 schreef Peter Palaga ***@***.***>
… Feel free to reopen if you feel this is not a duplicate of #1646
<#1646>
—
Reply to this email directly, view it on GitHub
<#1665 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6CPHNRBH6YNRQJUROV5S32F3J2NAVCNFSM6AAAAABTWEDCRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBVGY2TSNRXGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hi Peter, Unfortunately no luck for both Quarkus 3.16.4 with Quarkus CXF 3.16.1, and Quarkus 3.17.4 with Quarkus CXF 3.17.3. Adding the explicit port This gives a completely different error - now the connection to the server fails completely, instead of it receiving a 'http call to a https endpoint' message. I've tried both the 'regular' Note that my Reverting to the url without port (https://my.company.domain/something/else) continues to function in 3.15 and give the 'http call to a https service' application-error message on 3.16. Note that in 3.17 I never receive the application error, but only the error below. This is the error log when running 3.17 For completeness, here is my pom.xml showing the 'context' in which Quarkus CXF operates. <properties>
<compiler-plugin.version>3.13.0</compiler-plugin.version>
<maven.compiler.release>17</maven.compiler.release>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
<quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
<quarkus.platform.version>3.17.4</quarkus.platform.version>
<skipITs>true</skipITs>
<surefire-plugin.version>3.5.2</surefire-plugin.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>${quarkus.platform.group-id}</groupId>
<artifactId>${quarkus.platform.artifact-id}</artifactId>
<version>${quarkus.platform.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>${quarkus.platform.group-id}</groupId>
<artifactId>quarkus-cxf-bom</artifactId>
<version>${quarkus.platform.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>io.quarkiverse.cxf</groupId>
<artifactId>quarkus-cxf</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-rest-jackson</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-arc</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-rest</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-micrometer-registry-prometheus</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-junit5</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-junit5-mockito</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<scope>test</scope>
</dependency>
<!-- these datatypes are just POJOs, this dependency has no further dependencies -->
<dependency>
<groupId>my.company.datatypes</groupId>
<artifactId>datatypes</artifactId>
<version>17.10.0</version>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-openapi</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.36</version>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-config-yaml</artifactId>
</dependency>
</dependencies> |
|
I think some transistive dependencies are missing, when I added the following it started working... Will raise another issue for this. <dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-vertx</artifactId>
</dependency> |
|
Thanks for investigating further, @jcjveraa.
|
|
If 3.15 worked for you, could you please try if forcing the old default conduit via |
|
Hi again, sorry for the red herring for #1666. The 2nd item you mentioned seems to have been the culprit. Apparently configuring a trust store is not checked at startup (i.e. the app will start without it), but still mandatory. CXF doesn't throw an error when you specify a https based url without explicitly setting the trust store, but it won't work without specifying a trust store. When explicitly configuring a tls store it works. Note: the CA's for my case are in cacerts, I appreciate that often this would not be the case, but in my organization/in the base images we use it is. Should it not use the bundled trust store by default? With 3.15 this 'just worked' - perhaps it was using the bundled cacerts? quarkus:
cxf:
client:
xxx:
# ... other config
tls-configuration-name: xxx
tls:
xxx:
trust-store:
jks:
password: changeit
path: ${JAVA_HOME}/lib/security/cacerts |
Oh, I see, that's a very interesting case! Let me see what can be done about it. |
ppalaga
changed the title
VertxHttpClientHTTPConduit does not honor default Java truststore
|
@ppalaga I'll also second this issue - it's exactly the same problem for us. I finally had time to sit down and re-investigate the 302 Error, and it seems like the default server behaviour for us is to return a 302 with redirection to self and connection: close when TLS is not done. I compared the debug logs on URLConnectionHTTPConduit and Vertx, the difference was only the handshake... came to say something and saw this :) I also tried adding the tls-configurations and now it works. |
|
Thanks for the feedback, @dcheng1248. I have sent quarkusio/quarkus#45184 to Quarkus to make it easier to configure the default Java trust store. I still have to figure out whether it is a good idea to make the VertxHttpClientConduit fully compatible with URLConnectionHTTPConduit in this respect though. |
Out of curiosity (and for learning), what would be the arguments against it? In my (extremely limited) security knowledge, I would have assumed having a default security configuration for HTTP is preferred. Edit to add: quarkus property for trust store is awesome. It further simplifies our jvm command! |
|
Thanks for the explanation! I'm still a little confused and would appreciate some elaboration, only if you have time - do I understand correctly that the *.tls-configuration-name for extensions in general does not recognize the default java trust store like the current quarkus-cxf? Would that be something worth looking into? I'm unfamiliar with common use cases, but e.g. in our situation, we have all the certs in one trust store which we give to the JVM, and I'd expect all clients to look there by default... On that note, I seem to remember that the
I'm happy to help with that, if needed! |
Yes, I asked Clement, the author of TLS registry, exactly about that and he said, it is by design: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/Default.20truststore.20honored.20by.20Vert.2Ex.20based.20extensions.3F
I do not think there is much chances to change that on Quarkus level. But you may try to persuade Quarkus folks in the above Zulip chat. We may divert from Quarkus if we choose to. Drop in compatibility with URLConnectionHTTPConduit would be a strong reason to do that. |
I have not seen a reason to introduce an app-wide property so far. You may want to file a new issue if you find it important. |
|
@ppalaga I have the same issue. I using the option quarkus.native.additional-build-args=-J-Djavax.net.ssl.trustStore when building a native app to include a trust store. Would nice if vertx client would use this trust store. |
Edit by @ppalaga:
VertxHttpClientHTTPConduitdoes not honor the default Java trust store, typically${JAVA_HOME}/lib/security/cacertsunless the same file is configured explicitly inapplication.properties. This breaks the drop-in compatibility with the old defaultURLConnectionHTTPConduit.Original report by @jcjveraa :
Hi there, upgrading a quarkus microservice with this extension from 3.15 to 3.16 proves to be a bit of a challenge for me. I have read the changelogs etc. but cannot figure how to change my configuration to work again.
Issue: I'm sending my requests via a simple basic-auth over single-sided https to another server. With quarkus 3.15.1 this works fine. When trying to migrate to 3.16.4 (= cxf plugin 3.16.1) suddenly the https call seems to be downgraded to plain http, as the target server responds with a SOAP message containing an application-specific security error which occurs when sending http-requests to the https-endpoint.
The standard java
cacertsinclude the target server's CA certificates, in other words the host on which my application runs trusts the target server's certification path, so in principle no extra trust store should be required. Nevertheless I've tried setting up a tls config with just a trust store underquarkus.tls.xxx.trust-store.(etc.), but then it seems to try to go into mutual TLS mode as then it exits withFailed to create SSL connection? Not entirely sure, the error logging is cryptic at best.Any pointers are very welcome.
My quarkus config (in yaml-mode), working fine for 3.15:
The text was updated successfully, but these errors were encountered: