Forum Discussion
Erich_Rockman_1
Cirrus
CirrusAPM 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.
(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.
Erich_Rockman_1Thanks 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.
- Erich_Rockman_1
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.
