Forum Discussion

_KT_'s avatar
_KT_
Icon for Nimbostratus rankNimbostratus
May 02, 2020

Alignment between standard Virtual Server SSL verification and iRule events

Setup uses a client SSL profile applied on the VS - it specifies that a client certificate as required.

A CA bundle is specified to establish trust, and a CRL to confirm revocation status.

An attached iRule needs to inspect and base actions on the details of the client certificate (actions may drop connection).

My query is to understand what the status actually is once the CLIENTSSL_CLIENTCERT event is triggered.

Does this simply indicate that a certificate has been received, or will the main processing have also performed CA & CRL checking at this point?

i.e. does the event simply mean a client certificate is now available (but maybe isn't trusted or could be revoked), or does it mean that a client certificate has been received and is already verified (CA & CRL OK)?

If it is simply that a certificate is available but hasn't been verified then what event should actually be used in an iRule to work with the certificate after it is validated?

The steps that the iRule will perform will attempt to verify some other aspects of the client certificate, and drop the connection should these fail - so I presume this should really be done before the CLIENTSSL_HANDSHAKE event?

application delivery
iRules
LTM
security

3 Replies

Sort By
  • jaikumar_f5's avatar
    jaikumar_f5
    Icon for MVP rankMVP
    May 03, 2020

    I believe this is what your expecting,

    You can look for events details in here, and for the CLIENTSSL_CLIENTCERT

    You can define a data group for mutual authentication allowed lists and call that as well.

    when CLIENTSSL_CLIENTCERT {
if {[SSL::cert count] > 0 } {
if {[SSL::verify_result] == 0 }{
    set subject [X509::subject [SSL::cert 0]]
    set common_name [findstr [X509::subject [SSL::cert 0]] "CN=" 3 ","]
    set serial [X509::serial_number [SSL::cert 0]]
    set hash [X509::hash [SSL::cert 0]]
    log local0. "Client certificate details --> SUBJECT= $subject, COMMON NAME= $common_name, SERIAL= $serial, HASH= $hash"
} else {
log local0. "Client - [IP::client_addr] has provided an INVALID client certificate: [X509::verify_cert_error_string [SSL::verify_result]]"
}
} else {
log local0. "Client - [IP::client_addr] provided no cert."
}
}
    • _KT_'s avatar
      _KT_
      Icon for Nimbostratus rankNimbostratus
      May 03, 2020

      ​Thank you :-)

       

      One question just for confirmation if that is OK - apologies for the dumb questions I am just learning...

       

      The info for "SSL::verify_result" says "Gets the result code from peer certificate verification".

      I take it this means that the LTM has already checked the cert (CA & CRL), and this command just does a result lookup rather than actually making the LTM run the checks at the point the command is issued?

      • jaikumar_f5's avatar
        jaikumar_f5
        Icon for MVP rankMVP
        May 05, 2020

        Apologies on the late response, dint get any notification :/

         

        Its my understanding, that the LTM would use its own defined functions to validate it. The x509 is like a sub event itself. I have read some articles which said its similar to the openssl functions thats set to display the errors and others.

         

        I take it this means that the LTM has already checked the cert (CA & CRL) --> No, these are real time executions on the Irule. Whenever the VS gets the traffic, The Irule starts processing, it perform the checks.

         

        So lets say your client is sending a cert at 10 AM and has its connections established. Maybe after some idle time out, session gets closed. Again when the connection is established, the Cert will be validated again. We also have session resume which helps reduce the full tls. So the client cert check wont come into picture as its a resuming session. You can put logging to see when all what events are getting triggered.

        And by 11 AM if your cert is expired, and if its coming in a new connection, the LTM will capture it and will give a verify result code as 10.

         

        It wont perform CRL check everytime, that is something the browser (client machine) will perform with the CA endpoint.