Forum Discussion
NimbostratusCatch Dynamic CRL Errors and Return Friendly Page
Hi all,
I’ve implemented a TLS 1.3 mTLS HTTP virtual server, following the general instructions to support friendly HTTP errors as per Catch SSL Errors and return a friendly page... | DevCentral, with some slight adjustments. This has worked great and I’ve been able to catch errors through checks against the SSL::verify_result value. However, while this works using CRL File option, the behaviour is different when using Dynamic CRL.
It appears that using the CRL File option, all validation performed prior to the CLIENTSSL_CLIENTCERT event with the outcome provided in the SSL::verify_result. When using CRL Validator all non CRL validation performed prior to CLIENTSSL_CLIENTCERT, then CRL Validator performs its operations after CLIENTSSL_CLIENTCERT and before the CLIENTSSL_HANDSHAKE event, where the SSL::verify_result value can change based on the CRL Validator outcome. However, on most errors (from testing it appears to be all errors except for revoked status) processing fails and the CLIENTSSL_HANDSHAKE event is never reached. Instead, a TLS protocol response returned directly to the calling client, removing the opportunity to catch and process the error and return an HTTP response.
Has anyone configured catching SSL/TLS errors using Dynamic CRL and sending friendly HTTP responses? Any thoughts on how to address this? This is specifically to cover all the CRLDP failing scenarios, such as for all the “unknown” certificate status triggers and for certificates missing the CRLDP extension.
Thanks for any help
Andrew
2 Replies
kurokiAltostratus
bidders79 - did you ever resolve this? Seeing the same thing on the server side, verify_result = 0 when dynamic CRL responds revoked. Connection is reset with no apparent way to intervene via iRule
bidders79kuroki 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:
- 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)
- 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
- 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
- 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
