Forum Discussion
iRule URI Matching Not Working as expected.
- 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
}
}
you should use "ne" for the subject_dn comparison.
"!=" is for numeric
- sgamerFeb 07, 2025
Nimbostratus
You are correct that the statement should have been "ne" however a closer look at that statement proves it doesn't do anything in the iRule. It may have been a remnant from a previous version. Thanks!
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com