cancel
Showing results for 
Search instead for 
Did you mean: 

Passing Client certificate to pool members for authentication

RobertB
Nimbostratus
Nimbostratus

We are running LTM version BIG-IP 15.1.0.5 Build 0.42.8 Engineering Hotfix. We have a F5 virtual server configured with a client and server SSL profiles for termination and re-encryption. We have a request that the user of this virtual server wants to pass a client certificate for authentication. We want to pass the certificate via headers to the pool member servers vs controlling authentication on the F5. The backend application will process the certificate for authentication. I tried to create iRules to add the header but so far no luck.

I have tried something like:

 

when HTTP_REQUEST {

  HTTP::header insert X-Client-Cert [b64encode [SSL::cert 0]]

}

 

I have viewed other KBs with no luck, any help would be appreciated.

3 REPLIES 3

I think you need C3D here, the bigip creates a copy of the client certificate and passes to the backend server.

This is simple step, follow this KB - ​https://support.f5.com/csp/article/K14065425

Prakin
Altostratus
Altostratus

in this case C3D, i need to create a CA and that need to be configured on the server ssl profile and have to import on the server trust store as well. F5 will re-sign the client cert and send to serve for authentication, when it re-signs the server will use the locally generate CA or real client cert for authentication?. bit confused here. if using local CA generate means, then what's the point of client authentication on server side.

Kevin_Stewart
F5 Employee
F5 Employee

Client Certificate Constrained Delegation (C3D) is a mechanism to "forge" a new client cert on the server side. So BIG-IP would request and validate the real client cert on the client side, extract the attributes of that client cert and insert those into a new client cert dynamically created on the server side, and pass that to the backend servers. The forging mechanism requires a local "signing" CA certificate and private key on the BIG-IP, and the backend servers would need to trust this local CA. The point of this function to provide explicit decryption at the BIG-IP when the backend servers require a client certificate. Under normal circumstances a middle box could not decrypt mutual TLS traffic, because it wouldn't have access to the client's private key. C3D gets around this limitation by forging a new client (with a local private key) to the server. It's aptly named "constrained delegation", because like Kerberos, you can insert additonal information into the forged cert. So you could technically insert constraining identity and privilege information in the cert that the server could use to evaluate authorization.

The following is about integrating C3D with SSL Orchestrator, but goes into good detail on setting up C3D: https://community.f5.com/t5/technical-articles/ssl-orchestrator-advanced-use-cases-client-certificat...

But I'd like to go back to your original question. You said you wanted to pass the certificate to the servers via HTTP header, and you included an iRule that is technically correct. If you are requiring a client cert via the BIG-IP client SSL profile, then that value should be available in [SSL::cert 0]. Try inserting a log statement to see what you get:

when HTTP_REQUEST {
  log local0. [b64encode [SSL::cert 0]]
  log local0. [X509::subject [SSL::cert 0]]
  HTTP::header insert X-Client-Cert [b64encode [SSL::cert 0]]
}

If you see a set of values in the LTM log, then you should also see an HTTP header with this value at the server.