[
https://issues.apache.org/jira/browse/CXF-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radek Kraus updated CXF-9074:
-----------------------------
Description:
It seems {{HttpClientHTTPConduit}} does not respect custom {{SSLContext}}
registered in {{TLSClientParameters}} in case, when Java {{HttpClient}} is used
(when URLConnection is forced, then all is OK).
Let say, that I use {{HTTPConduitConfigurer}} to configure {{Bus}} to register
custom SSLContext into {{{}TLSClientParameters{}}}, something like this:
{code:java}
class SSLHTTPConduitConfigurer implements HTTPConduitConfigurer {
...
@Override
public void configure(String name, String address, HTTPConduit c) {
...
TLSClientParameters tlsClientParameters = c.getTlsClientParameters();
if(tlsClientParameters == null) {
tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setSslContext(sslContext);
c.setTlsClientParameters(tlsClientParameters);
}
...
}
...
}
bus.setExtension(new SSLHTTPConduitConfigurer(...),
HTTPConduitConfigurer.class);
{code}
At the moment, when I start the https/ssl communication (via Java
{{{}HttpClient{}}}), I received following exception (no certificate found).
{noformat}
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
at
java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:148)
at
java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:129)
at
java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
at
java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
... 26 more
{noformat}
But when I configure SSL (JSSE) by standard JDK way
({{{}javax.net.ssl.keyStore{}}}, {{{}javax.net.ssl.keyStorePassword{}}},
{{{}javax.net.ssl.trustStore{}}}), then all works as it is expected.
I tried to prepare [PR-2131|https://github.com/apache/cxf/pull/2131]with test
(and fix proposal)
was:
It seems {{HttpClientHTTPConduit}} does not respect custom {{SSLContext}}
registered in {{TLSClientParameters}} in case, when Java {{HttpClient}} is used
(when URLConnection is forced, then all is OK).
Let say, that I use {{HTTPConduitConfigurer}} to configure {{Bus}} to register
custom SSLContext into {{TLSClientParameters}}, something like this:
{code}
class SSLHTTPConduitConfigurer implements HTTPConduitConfigurer {
...
@Override
public void configure(String name, String address, HTTPConduit c) {
...
TLSClientParameters tlsClientParameters = c.getTlsClientParameters();
if(tlsClientParameters == null) {
tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setSslContext(sslContext);
c.setTlsClientParameters(tlsClientParameters);
}
...
}
...
}
bus.setExtension(new SSLHTTPConduitConfigurer(...),
HTTPConduitConfigurer.class);
{code}
At the moment, when I start the https/ssl communication (via Java
{{HttpClient}}), I received following exception (no certificate found).
{noformat}
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
at
java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:148)
at
java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:129)
at
java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
at
java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
... 26 more
{noformat}
But when I configure SSL (JSSE) by standard JDK way
({{javax.net.ssl.keyStore}}, {{javax.net.ssl.keyStorePassword}},
{{javax.net.ssl.trustStore}}), then all works as it is expected.
I tried to prepare PR with test (and fix proposal) - I will add a link a moment
later
> HttpClientHTTPConduit ignores SSLContext in TLSClientParameters (Java
> HttpClient)
> ---------------------------------------------------------------------------------
>
> Key: CXF-9074
> URL: https://issues.apache.org/jira/browse/CXF-9074
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 4.0.5
> Reporter: Radek Kraus
> Priority: Major
>
> It seems {{HttpClientHTTPConduit}} does not respect custom {{SSLContext}}
> registered in {{TLSClientParameters}} in case, when Java {{HttpClient}} is
> used (when URLConnection is forced, then all is OK).
> Let say, that I use {{HTTPConduitConfigurer}} to configure {{Bus}} to
> register custom SSLContext into {{{}TLSClientParameters{}}}, something like
> this:
> {code:java}
> class SSLHTTPConduitConfigurer implements HTTPConduitConfigurer {
> ...
> @Override
> public void configure(String name, String address, HTTPConduit c) {
> ...
> TLSClientParameters tlsClientParameters = c.getTlsClientParameters();
> if(tlsClientParameters == null) {
> tlsClientParameters = new TLSClientParameters();
> tlsClientParameters.setSslContext(sslContext);
> c.setTlsClientParameters(tlsClientParameters);
> }
> ...
> }
> ...
> }
> bus.setExtension(new SSLHTTPConduitConfigurer(...),
> HTTPConduitConfigurer.class);
> {code}
> At the moment, when I start the https/ssl communication (via Java
> {{{}HttpClient{}}}), I received following exception (no certificate found).
> {noformat}
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
> to find valid certification path to requested target
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:148)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:129)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
> ... 26 more
> {noformat}
> But when I configure SSL (JSSE) by standard JDK way
> ({{{}javax.net.ssl.keyStore{}}}, {{{}javax.net.ssl.keyStorePassword{}}},
> {{{}javax.net.ssl.trustStore{}}}), then all works as it is expected.
> I tried to prepare [PR-2131|https://github.com/apache/cxf/pull/2131]with test
> (and fix proposal)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
