Forum Discussion

Stefan_Klotz's avatar
Stefan_Klotz
Icon for Cumulonimbus rankCumulonimbus
Apr 24, 2023

Client-Certificate and IP-Whitelisting via Policy or iRule?

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...
application delivery
client-certificate
irule
policy
security
  • Michael_Saleem's avatar
    Michael_Saleem
    Apr 25, 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" }

  }
}
Stefan_Klotz's avatar
Stefan_Klotz
Icon for Cumulonimbus rankCumulonimbus

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 🙂

Michael_Saleem's avatar
Michael_Saleem
Icon for MVP rankMVP
Apr 27, 2023

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

 

  • Stefan_Klotz's avatar
    Stefan_Klotz
    Icon for Cumulonimbus rankCumulonimbus
    Apr 27, 2023

    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 🙂

    • Michael_Saleem's avatar
      Michael_Saleem
      Icon for MVP rankMVP
      Apr 27, 2023

      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.