Forum Discussion
Client-Certificate and IP-Whitelisting via Policy or iRule?
- Apr 24, 2023
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" } } }
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 🙂
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.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com