Layer7 API Management

Hi,

We are currently using a lot of SSL with client authentication with our b2b partners. We are validating the client certificate against a Group which contains a user that has the certificate coupled to it. For this to work, the name of the user needs to be the same as CN of the certificate.

Now we have a first case were the client certificate needs to be renewed. Idealy this is done by allowing both the old and the new for a short period of time to prevend the need of coordination between us and the b2b partner and more importantly to prevend downtime. However, as the renewed client certificate has the same CN, we cannot make a second user for this.

Any ideas to solve this? Any best practices on this topic?

The current only solution we are considering is validating against a Federated Identity Provider with the Intermediate of the Client Cert as Trusted Certificate and do a text-compare of the CN of the client cert in the policy itself.

Kind regards,

Tim

Tim,

I think your best option would be to use the Federated Identity Provider, as you would be able to import different certificates with the same CN without a problem, and then you could authenticate a user against any certificate that is present in the FIP. You should be able to import the client certificate instead of the intermediate certificate if you prefer. This would allow you to have a bit of overlap between the old and new certificate.

--Azad

Hi Azad,

We actually tried this solution (FIP with client certificate instead of intermediate) but this approach didn't seem to work.

Tim

Hi Azad, (and Mark_HE who marked Azad's reply for some reason as helpful while I already indicated this doesn't work?)

We again did the test.

Root was in our truststore as trustanchor.

First, we did a test with the intermediary on the FIP. This worked.

Then we changed it to have the leaf instead of the intermediary on the FIP. This failed.

So... this solution doesn't seem to work.

Have you tried to this yourself and got it working?

Tim

Tim,

I've setup this up in the lab and was able to get the scenario to work with 2 certificates that share the same subject name. STeps I took were:

1) Created a CA and Intermediate CA structure and signed 2 certificates with the CN of OU=Support,O=CA,C=CA,ST=BC,CN=communityusera against the Intermediate CA

2) Using the private key and a certificate chain including the leaf certificate, intermediate CA and CA created 2 P12 files for client mutual authentication

3) From the Policy Manager, imported the Intermediate CA into the Manage Certificates and checked "Signing Client Certificates" and Certificate is a Trusted Anchor.

4) Created a new FIP provider with the Intermediate certificate called Community. Once it was created then created a Virtual Group called CommunityUser with the X509 Subject DN as "OU=Support,O=CA,C=CA,ST=BC,CN=communityusera"

5) Created a new Service with the URI /cert and added in a Require SSL or TLS Transport with Client Certificate Authentication assertion, Authenticate against Group linking to the new Virtual Group, and a template response with something to let me know that it succeeded

6) Tested logging in against the new service with each of the newly created P12 files and making sure they were successful

This is a very locked in approach and can have issues if the newly updated certificate was not signed by the same certificate authority. 

I would suggest that you creating an Idea in our community on how you would like this to work.

Sincerely,

Stephen Hughes

Broadcom Support

Hi Stephen,

Thanks for your response. It has been a while so i can't remember if there was a difference in my approach vs yours. At first glance, it doesn't look like there is a difference. If I would find some time, I would test it out again to confirm your steps.

But, it is not so pressing anymore for use though, as we have figured out an alternative solution:

1. We have created two IDP's: a primary and a secondary.

2. We created a Group in style of 'b2bpartnerA.keys' on both of them.

3. We created a user with the client certificate and put it in the group

4. In policy, we first try user authentication wrt IDP primary. If that fails, we try IDP secondary.

When the client certificate needs to be renewed, we create the same user on secondary as on primary (with old cert) and change cert on the user in primary to have the new cert. This ensures no downtime and the b2b partner can choose when he switches based on his own convenience.

Downside: we have maintenance work when client certificate is being renewed

Upside: a bit more secure then the Federated IDP with Virtual Group as there's stronger leaf pinning

Kind regards,

Tim