For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Phl_72583's avatar
Phl_72583
Icon for Nimbostratus rankNimbostratus
Sep 24, 2008

Bypass OCSP for certain hosts

Hi all,

 

 

Disclaimer: An F5 novice throwing up a Hail Mary.

 

 

I have a client certificate used by an external entity - over which I have no control - that will not pass an OCSP validation. I need to force that certificate to be accepted by some "authentication profile" so it can be used to set up the two-way ssl session and thus be passed inside for further use by the app server - another asset I do not have access to.

 

 

I can't bypass authentication completely because the client certificate is needed for authorization purposes later. I can't send the cert in separately via an HTTP Header because I have no control over the app server.

 

 

The "authentication profile" in use is an OCSP Responder and is also the only means I have to authenticate. This is no other LDAP server or Radius server.

 

 

Is there a way to see that the cert is coming from a certain IP, force-accept it and continue with my handshake. I guess I'm looking for another option in the available authentication profile types - maybe a local cert store or local [ldap] repo of user creds - or just a way to cheat the code into thinking that the AUTH::authenticate call actually happened and returned successfully...

 

 

I would LOVE to simply get the external entity to use a valid cert...such is life. I realize that this could quite possibly be a horrible question not worth answering an I apologize for that in advance. I do hope you consider responding.

 

 

Thanks all.

 

 

application delivery
dev
devops
iRules

1 Reply

  • Phl_72583's avatar
    Phl_72583
    Icon for Nimbostratus rankNimbostratus
    Oct 15, 2008
    Thanks for the response. I intended to follow up but this fell through the cracks as it turned into a dead issue.

     

     

    You are correct that we did require client certificates and I had initially considered your suggestion. However, we needed the cert to come through the handshake so that we could then extract the identity of the user. So this was a backwards situation really - needing to use OCSP with the exception of one bad certificate that shouldn't pass anyway.

     

     

    It was a band-aid attempt. We finally found someone to take care of the cert and all was well.

     

    Thanks.