Catch Dynamic CRL Errors and Return Friendly Page

kuroki​ what you're describing seems like it might relate to this bug: https://cdn.f5.com/product/bugtracker/ID1009921.html

With respect to the remainder of my question, I did manage to get most of it working as needed, but required some additional checks in the iRule events to test and change the validation modes.  However, a number of the CRLDP errors are not caught and TLS native errors are returned.  This bug was opened to address these scenarios https://cdn.f5.com/product/bugtracker/ID2044457.html

With respect to the remaining behaviours, I had to:

1. in CLIENTSSL_CLIENTHELLO event set a default TLS error variable value (i.e. if processing fails after this point, default is the openssl lib failed)
2. in CLIENTSSL_CLIENTCERT get the openssl result code and check the number of requested certificates; if there were no certificates OR the error code was for bad certificate, unsupported/unknown issuer; then change SSL::cert mode to "ignore" (so it doesn't attempt to perform CRLDP on unknown certs); this outcome is considered a failure and handled in the HTTP request event later
3. in CLIENTSSL_HANDSHAKE get the openssl result code again (this is post CRLDP check), and only if both this event's openssl verify response and the openssl verify response in CLIENTSSL_CLIENTCERT are both success consider the process successful; unfortunately this step is impacted by the bug above for CRLDP validation failures for trusted certs
4. in HTTP_REQUEST check for the processing successful state and if failed then issue the HTTP::respond command

Some notes:

• I found that supporting the friendly messages was complex to configure, I cannot share the exact configuration
• a single connection may result in multiple events called prior to the HTTP request
• perform plenty of testing to consider all the certificate and CRLDP scenarios
• enable debugging as per https://my.f5.com/manage/s/article/K09322055