Forum Discussion

Erich_Rockman_1's avatar
Erich_Rockman_1
Icon for Cirrus rankCirrus
Apr 06, 2017

APM CRLDP Response

Hey all. I am able to use CRLDP cert check in APM (v11.6HF6). OCSP is not an option as the ocsp x509 extension does not exist in all my certs and I do not want to keep a list of issuers to OCSP profiles). Going through the scenarios (cert revoked, HTTP CRL not available, etc.). I am supporting multiple CAs, getting the CDP URL from the x509 extension in the cert. However, when the HTTP CRL is not available, I get an enrty in the apm debug logs (See the connection attempt to the CDP location in a tcpdump (SYN,SYN,SYN, etc. / No SYN ACK as its not available).

 

modules/Authentication/Crldp/CrldpAuthModule.cpp func: "setCrldpResponseStatus()" line: 796 Msg: Crldp Response Status: Bad HTTP response status and Following rule 'Successful' from item 'CRLDP Auth'

 

I wouldn't think this would be successful. In addition, the result is not in an APM session variable that I could parse.

 

A few observations/questions: 1. Is there a list of all the response codes that CRLDP returns so that I could parse and make my own decision? 2. The checkbox "Use Issuer" in the profile does the opposite of what it says. When not checked, it successfully pulls the CDP location from the cert. When checked, it doesn't. 3. Where can I see the cached CRL entries on the BigIP? Would be nice to be able to compare the entries to the result. 4. What is the "Allow NULL CRL" checkbox used for? In my testing it seems to do nothing.

 

Thanks.

 

BIG-IP Access Policy Manager (APM)
crldp
security
  • Erich_Rockman_1's avatar
    Erich_Rockman_1
    Icon for Cirrus rankCirrus
    Apr 26, 2017

    Guys. Hoping someone can shed some light on a related issue. If the CRLDP endpoint is unavailable, the CRLDP cache is not honored. It looks like it does a sweep before a successful download of the CRL file. This seems like a bug.

     

  • Erich_Rockman_1's avatar
    Erich_Rockman_1
    Icon for Cirrus rankCirrus
    Apr 08, 2017

    Thanks for the reply. I have done all that. The problem is that there is no extended information when the CRL cannot be contacted. This is in the sessiondump:

     

    414ca204.session.crldp./Common/Policy_act_crldp_auth_ag_1.result 1 1 414ca204.session.crldp.last.result 1 1

     

    while this is in the APM debug:

     

    modules/Authentication/Crldp/CrldpAuthModule.cpp func: "setCrldpResponseStatus()" line: 796 Msg: Crldp Response Status: Bad HTTP response status and Following rule 'Successful' from item 'CRLDP Auth'

     

    Not sure I would call that successful.

     

  • Josiah_39459's avatar
    Josiah_39459
    Historic F5 Account
    Apr 07, 2017

    (This is not a full answer to all your questions, but may be helpful)

     

    If you do a sessiondump on the session and grep for crldp

     

    sessiondump a834f3e | grep crldp

     

    you will see some entries like:

     

    a834f3e.session.crldp.last.result a834f3e.session.crldp.last.status

     

    An easy way to check them in testing is set a Message Box item after the CRLDP object so your policy doesn't finish and while you are sitting on the Message Box check the variables in the command line.

     

    Once you know how the variables are set you can use the "Empty" VPE object and set your own custom branching rules based on those values.