We have a flow service that was successfuly posting Purchase orders to our Vendor. Our Vendor has just upgraded their servers to 128-bit SSL. Since then we are getting Error 403 - Forbidden access.
We are now required to communicate with them using 128-bit cipher strength. Can someone give me some tips where to set this cipher strength ?. We use pub.client.http service within our service to do the HTTPS posting.
We are using SAP Business Connector(Web Methods server) 4.6 version in Windows 2000 - started our first project in Dec 2003
You should not have to make changes to IS for it to access a remote server that has either 40-bit or 128-but server certificates.
> Since then we are getting Error 403 - Forbidden access.
This is an HTTP return code. So SSL is not the problem - the SSL connection is setup, but then the server denies you access and sends back the 403 HTTP response headers through the SSL connection.
It’s likely your remote partner has HTTP Basic Authentication (username/password) and that is causing the 403.
The Vendor was doing the authentication even earlier for username, password etc. These have not changed - the validations were successful earlier but not after their upgrade to 128-bit.
The Vendor separately gave us a Java client to test the connectivity - we input the same parameters here also. This Client is able to communicate successfully where the webMethods server fails. We are even able to login using an Internet explorer browser. Looks like the HTTP settings in the webMethods server have to be changed.
What parameters are used for communicating successfully e.g. type of security credentials does your vendor require for accessing their system? Is it just basic (name & password) or mutual authentication (your client certificate)?
If the only change is that the vendor changed their server certificate, the things to look at are limited to a small scope.
If doing mutual auth, a change in the vendor’s cert has a couple of side-effects. The cert chain may not have the same CA in it as the old one. When doing mutual auth, the server determines which client certificate to present based off of the list of accepted CAs from the server. If your cert is not signed by one of those, no certificate is presented.
A little more information on how it worked before will go a long way in helping determine where to look.
Eduardo:
> The cert chain may not have the same CA in it as the old
That’s a good point in general. However, Vijay is getting an HTTP 403. So that rules out certificate authentication and SSL – if either were the problem, the underlying SSL channel wouldn’t be setup and
Vijay wouldn’t be able to receive an HTTP status code.
Vijay:
> We are even able to login using an Internet explorer browser.
Beats me Vijay - the only thing I can think of is perhaps the username password set in pub.client:http are incorrect?
The 403 is one way (ISS can do this) of indicating that client certificates are required; the other is by closing the connection at the SSL layer via an alert. Which action is performed is totally controlled by the target server.
Another thing to look at is if other configuration changes were made as part of the upgrade. For example the target server could be requiring digest authentication instead of basic.
OK thanks Eduardo - I didn’t know IIS behaves like this. I thought an SSL alert is mandatory when client certificate authentication is required but fails, and that it this always closes the connection.
Yes, it’s worth checking for configuration changes on the remote server. From the documentation on pub.client:http for IS 4.6, it appears to do Basic Authentication only.
> I had to install the SAP Business Connector 4.6 SSL version(128 bit).
Thanks for posting… Wow: I thought having seperate 40-bit and 128-bit versions of software had gone the way of the dodo since Netscape 4.
We had a similar 403 problem when our client communicates with our wM server after a machine upgrade. We are still working on the problem, but one thing we found out was the domain that the cert is issued to and the IP address must be the same as before. In other words, your vendors cert upgrade must not change the IP and the domain association.
