I have an issue in accessing a third party provided web service over https in WM 6.5. Has any one tried executing web services over https? What sort of steps are required in IS to set this up?

I’ve done the following.

1. I’ve imported the given WSDL file and created the web services connector. It shows the correct address as https://xxxx

2. We have also received the certificate in the *.pfx format to be used in a browser. Since we need to automate this task, I have imported this *.pfx file into IE. According to the IS Admin guide, I’ve exported this certificate from IE (using Oprions → Content → Certificates then select the certificate and click Export) to get the certificate in the .cer format.

3. Copied this certificate to the /config/certs/trusted folder (ie., after creating those folders)

4. Using the IS Admin Console → Certificates page added the above path to the Trusted Certificates (ie., CA Certificate Directory) entry and restarted IS.

When I call the web service via the web services connector, I get the StackOverflow error when it calls the pub.client.soapHTTP method.

It is not even communicating with the server.

In the past I have consumed many internal web services via http without any issues.

Any help would be appreciated?

Thanks
Maha

Can you give more details about the error message you are getting? Invoking Web Services via https does work. However your setup might not be completely correct. Turn up your log settings to 8 and then post your error message.

One thought, do you have the entire certificate chain in your trusted directory?

I have changed the log level to 10. The log file is attached. The log file shows that the pub,client.soapHttp was called to the correct address, but I do get Unhandled exception and the test code jumos to the catch sequence. The getLastError is showing the error as java.lang.reflect.InvocationTargetException:StackOverflowError

Call Stack shows the following.
Call Stack[0] pub.client:http
Call Stack[1] pub.client:soapHTTP
Call Stack[3] maha.owb_test.ws.MintWebService:submitReportBody (the web service flow imported by the WSC)

I’ve also attached the IS Java stacktrace from the error log.

Initially I was suspecting this. We have received a certificate file with *.pfx extension to be installed in the browser to access the data. Currently using the browser the business user can manually access the data. We are trying to automate this.

Check the steps 2, 3 and 4 in my initial post for the sequences I have followed to add the CA certificate (imported from the Browser) to the IS trusted directory. My guess is that I’m missing something in this set up.

Thanks
Maha
https_ws_log.txt (5.12 KB)
https_ws_error_log.txt (1.92 KB)

When you do a view cert. in IE, look at the chain for the certificate. You need to extract each one of those and copy it into your trusted CA directory.

I’m bit confused with this. I think the following steps are correct. Could you please check this.

1. In IE go to Internet Options → Content → Certificates

2. In the Certificates popup window select the certificate under Personal tab.

3. Click View to open the Certificate window, then select Details tab. Click “Copy to File” to save the certificate.

4. Select “Certificate Path” tab and for each certificate in the list follow step 3 to save the certificate.

5. Finally copy all the certificates to the Trusted CA directory.

I will follow the above and try it again.

Looks like maybe a bug with the version of the JDK you are using.

login to advantage and check out this article

[URL=“http://advantage.webmethods.com/article/?id=1611559245”]http://advantage.webmethods.com/article/?id=1611559245[/URL]

also look here

[URL=“http://java.sun.com/j2se/1.4.2/download.html”][COLOR=#0000ff]Oracle Java Technologies | Oracle

Thanks for the info. Replaced the policy files and now the pub.client:soapHTTP call actually works.

But the soapStatus is returned as 2.

the header shows the status as 403 and status message as “Forbidden”.

I’ve even tried with the password (using the optional auth/password field) provided for the browser client certificate *.pfx file, but still getting the above “Forbidden” message.

The input data is valid for the WS call.

I’m suspecting that the web service call is not authenticating the certificate with the external web server.

Can you work with the provider of the Web Service to see what’s going on the Web Server side? Generally, the IS server will throw a certificate error if there is a problem with the cert verification. You are verifying their cert not vice versi.

403 does point to some type of access problem, possibly the url, directory or username/password. They should be able to look at their logs though and see what the issue is.

How does IS know which certificate to use?

We have received the *.pfx file from the provider which has the certificate in it. We have installed this ie., using right click and selecting “Install PFX” which has opened the Certificate Import Wizard in Windows. According to the message the certificate is installed in the certificate store.

How does IS know that it has to use the same windows certificate store for client verification? I’ve exported the CA chain from IE and copied it to the Trusted CA directory (2 files).

I’ve also tried exporting the certificate without the private key so the file could be saved in the .der format. Copied this also to the Trusted CA directory, which I think is not necessary as the folder should contain only the CA certificates. I can’t export with the private key as the file would be saved as .pfx

Do I need to import the client certificate in IS using the Security->Configure Client Certificates option. I’ve once tried with the previously .der file, but no luck. I can’t import *.pfx file using this option.

I will confident that the URL is correct, but I will contact the provider to verify this.

After installing the *.pfx file IE can access the site. But FirFox has returned Forbidden message, similar to the IS. I’ve imported the *.pfx into FirFox and now it can display the contents of the URL. So the URL is correct.

I think the problem is that the certificate is not yet installed into IS. I’ve even tried the same URL using pub.client:http I’m getting the same Forbidden message ie., status code of 403. I’ve even entered the username, password for the “auth” field, but it didn’t help.

The problem is how do we import the client certificate which is provided in the .pfx format into IS? When I try this I get the following error.

ASN1: INTEGER does not support getComponentAt(int)!

I couldn’t find any information in the guides regarding this.

Edit:
I’ve used openSSL to convert the .pfx file to .DER format using the pkcs12 command. Then converted the .DER format to .PER format using the “openssl rsa” command as the .DER file shows the RSA key (there is no DSA key). I’ve tried this .DER file to import the client, but it throws the same ASN1: error.

The certificate contains a private key. If I remove the private key from the .DER file, it complains that the private key is missing.

Any clues to proceed from here?

I think I understand where you are now. I thought you had already configured the IS server to handler certs.

Step by Step

1- Export the public cert from IE, using cer format (DER encoded format).
2-Export the rest of the cert. chain(you will have trusted root and maybe an intermediate), one at the time, using cer format.
3- Place the .cer files in the IntegrationServer/config/certs/cas directory, you will have to create that directory structure.
4-In IS admin, CA Certificate Directory config/certs/cas
5-May have to restart IS depending on what version you are running. 6.5 you do not.

That’s all there is to it.

What?

I’ve already exported the certificate and the associated CA certificates (root and the intermediatory) as individual .cer files. They are already placed in a new folder under IS and the folder is specified for the Trusted CA folder.

I’m thinking that in addition to this we may also need to import the client certificate using “Configure Client Certificate” option.

There is a private key attached to the certificate, when I select this to be included in the export then the format of the file changes toe .p12 instead of .cer.

In IS admin, Select Security, Certificates. Edit Certs. Settings and fill out the location for your Trusted Certificates. CA Certificate Directory equals = config/certs/cas for example.

That’s all you need unless of course you turn off Certificate checking which you can.

watt.security.cert.wmChainVerifier.trustByDefault=true

He has referred the IS->Certificates-> Edit Certificate Settings then enter the folder in the Trusted Certificates section.

What I outlined is all you need to invoke a remote server with SSL via http. I just did this today for one of my servers. You don’t need the private cert and they shouldn’t give it to you.

I suspect the export is not completely correct or a setting is incorrect.

It was done as the first step before posting it in the forum.
What would happen to the private key which is attached to the certificate? It doesn’t get exported to the .cer format.

If things are going to work, then pub.client:http call to the URL should return something, but it returns 403. The browsers (both IE & FireFox) are showing the URL after applying the certificates.

My suspicion is that the attached private key has something to do with handshake.

The private key is not part of the certificate you have. It is used to generate the cert. request and stays with the resource used to generate the request. The private key is not given to a third party(that would be bad), you in this case. The public key is all you need along with the public keys in the chain.

When the IS server makes a call to an SSL resource, it compares the copy of the public key it has to what is being presented by the external resource, that’s the ssl handshake. If they don’t match, or if one is expired etc. then it fails.

To verify you are having a cert problem try putting in the following setting - watt.security.cert.wmChainVerifier.trustByDefault=true Restart the server and see if you still get the error.

This option is already set in server.cnf as the default value.

I can’t see anything wrong with the certificate export process.

Since we couldn’t proceed with this, we are going to tell the business user to use the existing browser interface to get the data manually as we are struggling to automate this. The service provider is not helpful as the service was provided by a third party application.

Thanks for the help in clearing things about SSL handshake and how to set up IS to invoke web services via https. At least we know that people do use IS to call web services via https.