I've seen plenty of examples of mutual TLS via a gateway generated client certificate, and I think I understand the setup well enough. For a B2B integration, is it possible to use the client's existing certificate without any change to the client side?
Is so, what are the setup steps specific to setting up client's existing certificate on the gateway, so that the gateway presents it as a certificate option during the "Require SSL or TLS Transport with Client Certificate Authentication" exchange? I just need to get to a point where it shows in context variable "request.ssl.clientCertificate". I believe I understand how to validate it against an internal identity provider once I get the context variable populated.
The examples you may have seen around Client Mutual Authentication with Gateway generated private keys works the same for client certificates that clients bring themselves. The main things to consider is that you need to have the following:
1) Use the Require SSL with Client Mutual and the Authenticate against the identity provider. (Note: don't worry about the context variable you have outlined just so long as the client certificate is presented)
2) Import the signer CA certificate that the client used into the Manage Certificates and make sure that the option Sign Client Certificates is checked so for TLS 1.1 and 1.2 a trusted CA list has their signer in it. Do you import the client public certificate as it was not used to sign it unless it is self signed.
3) Add the user to either the internal identity provider or to a FIP provider with their public certificate. The username needs to match the cn value of the certificate to function properly.
Director, CA Support
We have successfully configured mutual client certificate authentication when using self-signed certificates - with the gist of the procedure being:
1. Create the self-signed cert. Keep the keystore because it is required when setting up SOAP UI.
2. Import the cert as a Trust Anchor and select the Signing Client Certificates option.
3. Create federated identify provider.
4. Create user - DN as name, additional properties - import self-signed cert created in step 1.
5. Confirm user (cert) exists in FIP.
6. In API, add assertions (Require SSL or TLS Transport with Client Certificate Authentication, Authenticate Against Identity Provider).
7. Select the FIP that you created in step 3 as the target for Authenticate Against Identity Provider assertion.
8. Save changes and then test in SOAP UI. Note that SOAP UI requires the jks when it is configured for mutual client cert testing.
This set up works when self-signed certs are used and the configuration is tested with SOAP UI.
This set up does NOT work when the external B2B partner provides its certificate.
Why does this not work in this scenario.
The only difference that I can see is that SOAP UI has access to the self-signed cert's private key, because that configuration points to the certificate's java keystore.
Note: In SOAP UI, I can mimic the failure I see when testing with external client applications by removing the keystore from the configuration or by submitting an incorrect password for the keystore.
I have a similar problem, it does not work when it is B2B ...
Did you solve it?