Unable to send data via WebService

Hello there,

We are having a serious problem when trying to send data via webService to our partner. 
Our partner has provided us with a machine certificate of type PKCS12 (.p12) and a password for it.
This is how we set the transfer up:
  1. From the IS admin page we created a new Keystore Alias (type PKCS12, Provider: SunJSSE, HSM Based Keystore: false) based on the certificate (the import was successful).
  2. Created a new webService consumer endpoint (TransportType: HTTPS, Keystore Alias: the one previously created, Key Alias: selected from the dropdown based on the keystore alias created at step 1).
  3. At the pub.client.soapClient service passed as input (beside the inputs needed for the WS) the endpointAlias created at step 2.

The pub.client.soapClient service returns a fault. The error is following:
com.wm.app.b2b.server.ServiceException: org.apache.axis2.AxisFault: Server certificate rejected by ChainVerifier

Following properties are set at IS server level:

watt.security.allowInternalPasswords=false
watt.security.CAFingerprints=
watt.security.cert.wmChainVerifier.enforceExtensionsChecks=false
watt.security.cert.wmChainVerifier.trustByDefault=true
watt.security.decrypt.keyAlias=ssos
watt.security.decrypt.keyStoreAlias=DEFAULT_IS_KEYSTORE
watt.security.fips.mode=false
watt.security.hw.ncipher.standardPort=
watt.security.keyStore.supportedTypes=JKS, PKCS12
watt.security.KeystoreAndTruststore.defaultAliasCreated=true
watt.security.ope.AllowInternalPasswordAccess=false
watt.security.pub.getFile.checkReadAllowed=false
watt.security.session.forceReauthOnExpiration=false
watt.security.sign.keyAlias=ssos
watt.security.sign.keyStoreAlias=DEFAULT_IS_KEYSTORE
watt.security.ssl.cacheClientSessions=false
watt.security.ssl.client.ignoreEmptyAuthoritiesList=false
watt.security.ssl.ignoreExpiredChains=true
watt.security.ssl.keyAlias=ssos
watt.security.ssl.keypurposeverification=false
watt.security.ssl.keyStoreAlias=DEFAULT_IS_KEYSTORE
watt.security.trustStore.supportedTypes=JKS
watt.security.trustStoreAlias=DEFAULT_IS_TRUSTSTORE

Our IS details:
Version: 9.9.0.0
Fix level: IS_9.9_Core_Fix11

Do you have any idea if we are doing anything wrong?
We also tried to recreate the WS consumer and endpoint Alias but with no effect.

Thank you in advance,
n23

Hi,

sounds like you are not trusting the CA of the servers certificate of your partner.

Can you check if this certificate has valid CA, which is usually trusted by default by using the cacerts file from the JVM, or if it is a self-signed certificate?

For the second case create a Truststore Alias for PKCS#12 file the same way you have created the Keystore Alias.

Regards,
Holger

Hi Holger,

I believe the client certificate is self signed. I edited the watt.security.trustStore.supportedTypes property to add PKCS12 type and then created a new truststore alias based on the provided certificate. Then I added the Truststore alias in the WS Endpoint settings in WS Security Properties. Unfortunately I get the same error.

Thanks,
n23

Hi,

did your clear the SSL cache (under Security → Certificates)?

Are you able to access the remote webservice via Browser?
If yes you can examine the certificate and its CA chain within the browser.

Regards,
Holger

Hi Holger,

I tried resetting the SSL cache but it is still not working.
I accessed the WSDL via browser then went to Inspect - > Security → VIew Certificate. What am I looking at exactly?

Thanks,
n23

Hi Bogdan,

please check the validity period as well as the issuer´s certificate.

Assign the Truststore under Security → Certificates as the Truststore and restart the IntegrationServer.

Regards,
Holger

Hi Holger,

The certificate is valid until 2018. This is what I did:

View Certificate → Copy to file

Then I used the certtool to add the certificate to the default truststore DEFAULT_IS_TRUSTSTORE (using ./certtool -add). Afterwards I added the DEFAULT_IS_TRUSTSTORE in the WS endpoint alias in the WS Security Properties. Then I cleared the SSL Cache and reloaded the default truststore.
Now it seems to be working.

What I don’t understand is why it worked before (by just setting the keystore alias in the WS Endpoint settings and without setting a truststore)

Thanks,
Bogdan