C3D forged certificate

[Sarah]

Hello Community,

I have a service that requires client authentication "mutual TLS" between the app server and the client.

Since BIG-IP is in between, I configured my virtual server to use C3D (Client Certificate Constrained Delegation) following KB https://my.f5.com/manage/s/article/K14065425 

However, the app server is  unable to authenticate the client and getting "invalid thumbprint" in server logs.

I wonder what information used from the original client certificate in order for BIG-IP to generate the forged client certificate for use in server-side client certificate authentication?

and if there is anyway to pass the certificate thumbprint to app server? maybe utilizing "Custom Certificate Extensions" in server-ssl profile?

Thank you

[Leslie_Hubertus]

Hi @Sarah - I see nobody from the community has answered this yet, so I'm featuring it in today's Community Highlights article to help boost visibility and hopefully get you an answer more quickly. 

[Kevin_Stewart · Accepted solution]

Here's another resource for C3D configuration: https://community.f5.com/t5/technical-articles/ssl-orchestrator-advanced-use-cases-client-certificat... It's specific to SSL Orchestrator integration, but goes into details on the C3D setup and various use cases.

Per your question, C3D forges a new client certificate, signed/issued from your local CA. During the forging process, C3D will copy important attributes over from the real certificate, including subject CN, any extensions you specify to be copied in the "Certificate Extensions" setting in the server SSL profile, plus any that you may inject via SSL::c3d iRules. It won't have the same issuer, fingerprint, thumbprint, etc. because it's effectively a new certificate from a different issuer. Your internal application needs to be able to validate client certificates from this new/local CA. 

[Kevin_Stewart]

Just realized the above article link didn't work. Here it is again:

SSL Orchestrator Advanced Use Cases: Client Certificate Constrained Delegation (C3D) Support 

[Daniel_Wolf]

I guess I am late to the party, but I wanted to add some observations from my experience.
In the Server SSL profile where you configure the CA Certificate & Key it is important to use a certificate that has ability to issue new certificates, for example a SubCA certificate.
The BIG-IP will then use this cert to issue a new certificate based on your client cert and it will send this cert plus the SubCA cert to the pool member.

On the pool member, I used NGINX in my test, you need to store the chain (Root and SubCAs) the file referenced in ssl_client_certificate directive.

KR
Daniel

[Kevin_Stewart]

Great point @Daniel_Wolf.  The minimum qualifications for a certificate authority would be:

Basic Constraints: critical
CA:TRUE
Key Usage:
   Digital Signature (digitalSignature)
   Certificate Sign (keyCertSign)

It doesn't have to be a subordinate CA. Can be a root. But it's certainly more practical (and secure) to use a subordinate CA for these functions.

[Daniel_Wolf]

@Kevin_Stewart - IMHO this bit of information should be mentioned in the K14065425 article. Not some knowledge that is handed-down from seasoned F5 master to padawan. 🙂

[Sarah]

Thank you All @Kevin_Stewart, @Daniel_Wolf, and @Leslie_Hubertus. I truly appretiate your support!

I do agree with @Daniel_Wolf, while I was searching on this subject (C3D) I found a little to no details on F5 KB articles, I wished the articles were more detailed it would have saved more time.

Thank you again.