Forum Discussion

mlanghorst's avatar
Icon for Nimbostratus rankNimbostratus
May 23, 2023

Client Cert authentication for specific url issues. curl breaks

I have an odd use case, moved a site from Apache that had a Location setting that would require client authentication for only a specific uri "/transout", and not prompt for a cert for any other requests.

So I created a rather simple APM policy of "On Demand Cert Auth" and a Variable Assign to log the user request in the APM policy.

Then in an irule:
if { [string tolower [HTTP::path]] contains "/transout" } {
HTTP::header insert "clientless-mode" 1
ACCESS::enable} ACCESS::disable

This works fine for a browser,  but curl just breaks on a 302 to my.policy, even with a -L to follow redirects, then to a /my.logout.php3?errorcode=19.  The apm log only logs that there's a new session from Clientip.  Log statements on the fail branch of on-demand cert auth don't execute.

Is there a better way to protect only that /transout url?

3 Replies

  • What curl command are you trying to run? Presume that with /transout as the path in the request, you are presenting the certificate via curl as well?

























  • Command, with just the domain changed:
    curl -v -k -L --cert ./mlanghorst_cert.pem --key mlanghorst_key.pem

    Executing this against a Virtual server that requires client cert for all requests works fine.  Also, in the APM log all I see is that a new session was established.  In the APM policy, I have log statements for both success and failure branches of the On Demand Cert, but neither are executed.

  • Don't have access to full desktop/laptop because still at Red Hat conference. However, I would double check the following:

    - iRule appears to be missing the the else clause. Essentially you are issueing the if statement and then disabling APM on that particular path, but right afterward you are re-enabling it again. So this may need to be restructured.

    - There are 2 different APM policies. One is session based and generally used to authenticate the user to a resource. The other is a per request policy. The later may be more appropriate as you want to check user access on each HTTP/HTTPS request and selectively permit/deny access.

    Hope this at least helps to reframe the issue and provide some ideas for further troubleshooting.