Forum Discussion

sgamer's avatar
sgamer
Icon for Nimbostratus rankNimbostratus
Feb 05, 2025
Solved

iRule URI Matching Not Working as expected.

We have a virtual server that has these three requirements: mTLS negotiation Match start of URI Match CN of certificate Note: The the virtual server where this iRule is applied does not have a ...
  • f51's avatar
    Feb 06, 2025

    It seems like you're having trouble with an iRule, that's supposed to handle mutual TLS (mTLS) negotiation, URI matching, and certificate validation based on the Common Name (CN). The problem you're encountering is that sometimes a bogus URI gets through even after it should have been rejected. This might be due to caching or session persistence issues.

     

    Try this  

    when CLIENTSSL_CLIENTCERT {
        set subject_dn [X509::subject [SSL::cert 0]]
        log local0. "CLIENTSSL_CLIENTCERT: subject_dn=$subject_dn"
    }

    when HTTP_REQUEST {
        log local0. "HTTP_REQUEST: uri=[HTTP::uri] subject_dn=$subject_dn"
        if { [HTTP::uri] starts_with "/uri-a" } {
            if { $subject_dn contains "mauth-a" } {
                log local0. "Matched /uri-a and mauth-a"
                pool serverpool-a-443
            } else {
                log local0. "Matched /uri-a but did not match mauth-a"
                reject
            }
        } elseif { [HTTP::uri] starts_with "/uri-b" } {
            if { $subject_dn contains "mauth-b" } {
                log local0. "Matched /uri-b and mauth-b"
                pool serverpool-b-443
            } else {
                log local0. "Matched /uri-b but did not match mauth-b"
                reject
            }
        } else {
            log local0. "No URI match found, rejecting"
            reject
        }
    }