oops that bit about “They should also have put your certificate under Security > Certificates > Client Certificates (or if they use TN, under their TP profile for you).” only applies if you are POSTing to them and they are using client certificates to authenticate you.
For you to accept their client certificate when they are POSTing to you, you need to have done the above on your BC for their client certificate and likewise you also need to have their root (and intermediate) signing certificates (that are used by their client certificate) in your BC Trusted Certificates directory (as .der files).
If you are using an IS reverse invoke in your DMZ, then you ‘should’ have their root (and intermediate) signing certificates (that are used by their client certificate) in your IS reverse invoke Trusted Certificates directory. Their client certificate does not need to be in the IS reverse invoke however, as it will be BC that checks it.
One reason for having their root (and intermediate) signing certificates in your IS reverse invoke Trusted Certificates directory is for testing purposes, so that when they use a browser from their server and they have their client cert. in the keystore used by this browser, during the HTTPS session negotiation it will popup a list of certificates that are installed in their keystore that your server will accept.
Hope this isn’t confusing.
You could try turning off ‘request client cert.’ on your port if want to remove this from part of the problem until you nail it down further.
#Integration-Server-and-ESB#webmethods-Protocol-and-Transport#webMethods