24-Apr-2023 08:11
We have a requirement to verify for a valid client-certificate (not expired and issued from a trusted CA), but also accept a bypass if the source-IP is trusted. I have the following questions for the two different configuration options:
Policy
Assuming above mentioned policy-setup is not possible, I would configure the client-cert check within an iRule.
iRule
Thank you!
Regards Stefan 🙂
Solved! Go to Solution.
24-Apr-2023 20:15
I would approach this by having two separate client SSL profiles - one without client authentication (bypass) and one with client authentication (require). And then use an iRule to switch between them based on the source IP.
create ltm profile client-ssl CLIENTSSL-NO-CLIENT-AUTH defaults-from <PARENT CLIENT SSL PROFILE> cert-key-chain add { <CERT KEY CHAIN NAME> { cert <CERT NAME>.crt key <KEY NAME>.key chain <CA BUNDLE NAME>.crt } }
create ltm profile client-ssl CLIENTSSL-CLIENT-AUTH defaults-from <PARENT CLIENT SSL PROFILE> cert-key-chain add { <CERT KEY CHAIN NAME> { cert <CERT NAME>.crt key <KEY NAME>.key chain <CA BUNDLE NAME>.crt } } peer-cert-mode require ca-file <ROOT CA NAME>.crt
create ltm data-group internal DG-SSL-CLIENT-AUTH-BYPASS type ip records add { <WHITELISTED IP 1> <WHITELISTED IP 2> ... }
when CLIENT_ACCEPTED {
set DEBUG 0
set CLIENT_IP [IP::client_addr]
if { [class match $CLIENT_IP equals DG-SSL-CLIENT-AUTH-BYPASS] } {
# Skip SSL client authentication for whitelisted source IPs
SSL::profile CLIENTSSL-NO-CLIENT-AUTH
if { $DEBUG } { log local0. "$CLIENT_IP - SSL client authentication bypassed" }
}
else {
# Enforce SSL client authentication for all other source IPs
SSL::profile CLIENTSSL-CLIENT-AUTH
if { $DEBUG } { log local0. "$CLIENT_IP - SSL client authentication enforced" }
}
}
24-Apr-2023 20:15
I would approach this by having two separate client SSL profiles - one without client authentication (bypass) and one with client authentication (require). And then use an iRule to switch between them based on the source IP.
create ltm profile client-ssl CLIENTSSL-NO-CLIENT-AUTH defaults-from <PARENT CLIENT SSL PROFILE> cert-key-chain add { <CERT KEY CHAIN NAME> { cert <CERT NAME>.crt key <KEY NAME>.key chain <CA BUNDLE NAME>.crt } }
create ltm profile client-ssl CLIENTSSL-CLIENT-AUTH defaults-from <PARENT CLIENT SSL PROFILE> cert-key-chain add { <CERT KEY CHAIN NAME> { cert <CERT NAME>.crt key <KEY NAME>.key chain <CA BUNDLE NAME>.crt } } peer-cert-mode require ca-file <ROOT CA NAME>.crt
create ltm data-group internal DG-SSL-CLIENT-AUTH-BYPASS type ip records add { <WHITELISTED IP 1> <WHITELISTED IP 2> ... }
when CLIENT_ACCEPTED {
set DEBUG 0
set CLIENT_IP [IP::client_addr]
if { [class match $CLIENT_IP equals DG-SSL-CLIENT-AUTH-BYPASS] } {
# Skip SSL client authentication for whitelisted source IPs
SSL::profile CLIENTSSL-NO-CLIENT-AUTH
if { $DEBUG } { log local0. "$CLIENT_IP - SSL client authentication bypassed" }
}
else {
# Enforce SSL client authentication for all other source IPs
SSL::profile CLIENTSSL-CLIENT-AUTH
if { $DEBUG } { log local0. "$CLIENT_IP - SSL client authentication enforced" }
}
}
27-Apr-2023 01:26
Dear Michael,
thank you for your quick and useful response. This sounds indeed for an easy solution, at least for the iRule-option. But besides this, I'm still interested for an answer for the policy option. I mean which technical options do I have in regards to client-certificate verification? Is it really only the CN, which can be checked or other values like within iRules as well?
Regards Stefan 🙂
27-Apr-2023 02:07
Hi Stefan,
I have checked this on TMOS v16 and it looks like you are correct. In a local traffic policy, you can only check the common name with the option of using 'index' to exactly specify which certificate you would like to check (e.g. the identity certificate or intermediate certificate that the client sends)
root@(bigip-1)(cfg-sync In Sync)(Active)(/Common)(tmos)# create ltm policy Drafts/foo strategy first-match rules add { bar { ordinal 0 conditions add { 0 { ssl-cert ?
Selectors
common-name Organization common-name specified in certificate
Params
index Numeric index to match
27-Apr-2023 13:33
Thanks again for confirmation!
Final question, am I right that checking the CN via Policy (or iRule) is just a string comparison and therefor less secure than using the "Trusted Certificate Authorities" from the clientSSL-profile? Or the other way round, what's the technical mechanism behind the "Trusted Certificate Authorities"? I mean which value from the configured certificate bundle will be used for verification? Is it the serial number, the hash-value or something else?
Regards Stefan 🙂
27-Apr-2023 13:57
Yes. The "Trusted Certificate Authorities" setting in the client SSL profile is the crucial bit for client authentication and establishing that chain of trust.
With client authentication:
1) The client will send their own identity certificate (e.g. CN=bob) and the intermediate certificate
2) When you specify a Trusted Certificate Authority on the F5, you specify the Root CA certificate which chains back to the intermediate certificate which the client sent. If the public key from the Root CA certificate can successully decrypt the digital signature on the intermediate certificate, then it knows that the client certificate can also be trusted.
10-May-2023 09:39
Sorry for the late reply, but I'd like to inform you, that we have successfully implemented our requirement with the above mentioned iRule with a small difference.
Thanks again for your help!
Regards Stefan 🙂
10-May-2023 11:51
That's great. Glad I could help. I also agree with those modifications you made - it simplifies the configuration.