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
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: