On Thu, 2017-05-18 at 23:54 -0300, Jonathan Barbero wrote:
> Hi,
>
> I'm using the version 4.5 of HttpClient on a servlet in a WAS 7
> calling to
> another WAS 7.
> When I test the call with http protocol everything works. But when I
> try
> with https the call fails because "Chaining certificate error", the
> certificate of the CA is not recognized as trusted.
>
> The CA certificate is in the WAS truststore. When we call in another
> app
> with a JAX-WS client over https to the same endpoint it works, so it
> get
> the CA certificate from the truststore. Also, I capture in the WAS
> log that
> when it starts the app server loads the CA certificate as trusted
>
>
> [5/18/17 18:17:39:867 ART] 00000000 CSIServerRI A JSAS0008I:
> Server
> request interceptor registered.
> [5/18/17 18:17:39:878 ART] 00000000 SecurityCompo A JSAS0009I: IOR
> interceptor registered.
> [5/18/17 18:17:40:732 ART] 00000000 SystemOut O adding as trusted
> cert:
> [5/18/17 18:17:40:734 ART] 00000000 SystemOut O Subject:
> CN=CABNA,
> DC=cc, DC=bna, DC=net
> [5/18/17 18:17:40:737 ART] 00000000
> SystemOut O Issuer: CN=CABNA,
> DC=cc, DC=bna, DC=net
> [5/18/17 18:17:40:744 ART] 00000000 SystemOut O Algorithm: RSA;
> Serial number: 0x476da8f2b43899b24dfe7a94e66a1b7f
> [5/18/17 18:17:40:747 ART] 00000000 SystemOut O Valid from Mon
> May 09
> 12:38:13 ART 2016 until Sat May 09 12:48:13 ART 2026
> [5/18/17 18:17:40:748 ART] 00000000 SystemOut O
>
>
> But when I call my servlet and this one tries to call with an
> HttpClient to
> the other WAS over https, I captured that it does not load the same
> truststore of the WAS
>
>
> [5/18/17 18:22:36:965 ART] 00000028 SystemOut O keyStore is:*
> /opt/IBM/WebSphere/AppServer/java/jre/lib/security/cacerts*
> [5/18/17 18:22:36:965 ART] 00000028 SystemOut O keyStore type is:
> jks
> [5/18/17 18:22:36:965 ART] 00000028 SystemOut O keyStore provider
> is:
> [5/18/17 18:22:36:965 ART] 00000028 SystemOut O init keystore
> [5/18/17 18:22:37:237 ART] 0000000d SystemOut O Finalizer thread,
> called close()
> [5/18/17 18:22:37:237 ART] 0000000d SystemOut O Finalizer thread,
> called closeInternal(true)
> [5/18/17 18:22:37:237 ART] 0000000d SystemOut O Finalizer thread,
> called close()
> [5/18/17 18:22:37:237 ART] 0000000d SystemOut O Finalizer thread,
> called closeInternal(true)
> [5/18/17 18:22:37:248 ART] 00000028 SystemOut O
> SSLContextImpl: Using
> X509ExtendedKeyManager com.ibm.jsse2.hd
> [5/18/17 18:22:37:250 ART] 00000028 SystemOut O trustStore is:
> */opt/IBM/WebSphere/AppServer/java/jre/lib/security/cacerts*
> [5/18/17 18:22:37:250 ART] 00000028 SystemOut O trustStore type
> is: jks
> [5/18/17 18:22:37:250 ART] 00000028 SystemOut O trustStore
> provider is:
> [5/18/17 18:22:37:250 ART] 00000028 SystemOut O init truststore
> [5/18/17 18:22:37:253 ART] 00000028 SystemOut O adding as trusted
> cert:
> [5/18/17 18:22:37:253 ART] 00000028 SystemOut O Subject:
> CN=Certum
> Trusted Network CA, OU=Certum Certification Authority, O=Unizeto
> Technologies S.A., C=PL
> [5/18/17 18:22:37:254 ART] 00000028
> SystemOut O Issuer: CN=Certum
> Trusted Network CA, OU=Certum Certification Authority, O=Unizeto
> Technologies S.A., C=PL
> [5/18/17 18:22:37:254 ART] 00000028 SystemOut O Algorithm: RSA;
> Serial number: 0x444c0
> [5/18/17 18:22:37:254 ART] 00000028 SystemOut O Valid from Wed
> Oct 22
> 10:07:37 ARST 2008 until Mon Dec 31 09:07:37 ART 2029
> [5/18/17 18:22:37:254 ART] 00000028 SystemOut O
> .............
> .........
> ... and so on
>
>
> seems like the HttpClient loads the certificates in cacerts of the
> JVM only.
>
> So, I modified the creation of the HttpClient and
> added useSystemProperties()
> because I read that this might take the truststore of the WAS, but
> didn't
> work.
This should make HttpClient pick up the system SSL config. You can also
force the use of system SSL config this way
CloseableHttpClient client = HttpClientBuilder.create()
.setSSLSocketFactory(SSLConnectionSocketFactory.getSystemSocket
Factory())
.build();
If it does not work there likely to be a problem with the WAS SSL
setup.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
