Layer 7 API Management

Expand all | Collapse all

API GW - OCSP / CRL only use outbound proxy

  • 1.  API GW - OCSP / CRL only use outbound proxy

    Posted 10-04-2017 01:19 PM

    I've run into a little issue with the API GW on an internal network and trying to see if anyone has run into it or knows a way around it.


    We trust a number of issuers for certificates external to us. Their OCSP/CRL locations are out on the public internet but the user may be inside our private network. So the API GW needs to go outbound to the internet to retrieve those decisions.


    I see there's Default HTTP Proxy and other options for setting up a proxy. The problem there is that it would be proxying all the traffic or for known hosts, right?


    In this case, the locations vary based on the issuer and that issuer list is regularly updated. That location may also change in a cert without us knowing (rare but possible). I don't want to send all traffic out via that proxy but do need the OCSP/CRL checks to go outbound through it....


    Is there any way to force just OCSP/CRL revocation checks to use the outbound proxy?

  • 2.  Re: API GW - OCSP / CRL only use outbound proxy

    Posted 10-08-2017 06:06 PM

    Good afternoon,


    The best option would be to use the Manage HTTP Options without the default set as this will allow you to control individual hosts that you want to connect to and how they are handled for OCSP/CRL, WSDL/Schema import, etc but not for how the HTTP Routing Assertion works. The HTTP Routing assertion utilizes the settings it has in its assertion to either use a proxy or not.





    Stephen Hughes

    Director, CA Support

  • 3.  Re: API GW - OCSP / CRL only use outbound proxy

    Posted 10-09-2017 10:52 AM

    Don't think I can do it on a "per host" basis, at least not easily. We don't track the OCSP/CRL endpoints for all the external CAs, and a single issuer could even have multiple.


    However, if the "default" doesn't apply to the route...Could I just set the "default proxy" to our outbound one and then on all the routes have it set for "Do not use an HTTP proxy"? Missed this statement on the Docops 'The HTTP options do not apply to HTTP routing, only to other HTTP(S) connections." that might work; Guess it would still send out LDAP queries etc via that proxy.


    The ultimate goal is to limit what outbound goes through that proxy. So how about going the other direction then. We know what SQL/LDAP hosts would be and that's static, well defined hostnames. 


    Something like:


    Default HTTP Proxy = set for our outbound public proxy

    LDAP Hostname = No Proxy

    SQL Hostname = No Proxy


    Seems like that might work?

  • 4.  Re: API GW - OCSP / CRL only use outbound proxy

    Posted 10-09-2017 12:09 PM



    Manager HTTP Options only affects HTTP interactions not LDAP, SQL, or JMS. You can set the Default Proxy and then if you need WSDL imports and such then you can align either individual entries with wildcard for internal entities.




    Stephen Hughes

    Director, CA Support

  • 5.  Re: API GW - OCSP / CRL only use outbound proxy

    Posted 10-09-2017 12:47 PM

    Seems like trying that is the best option then (default HTTP proxy). 


    If LDAP isn't included, would just be a problem for CRL checking if there's not an HTTP endpoint. Not sure if that'd be any issues or not, but I'm assuming they all have an HTTP OCSP assuming it'd be alright.


    We're not in PROD yet, just now working on deploying the product. Will give it a try.


    Thanks for all the info and help.


    Edit: Talked to PKI guys and looks like HTTP began being required for hopefully won't be an issue.

  • 6.  Re: API GW - OCSP / CRL only use outbound proxy

    Posted 10-17-2017 04:34 PM

    I also have to support this exact use case. If you don't mind, please post the results of your tests.

  • 7.  Re: API GW - OCSP / CRL only use outbound proxy

    Posted 12-05-2017 01:12 PM

    So far no luck...Proxy is setup, but traffic does not seem to be going out when it's doing the OCSP/CRL. Possible I set something wrong, still new to this thing. 


    It's actually worse than I thought, because by default the product wasn't doing any revocation checking for anything - which wasn't turned on the LDAPS (thought it was...too many configs to flip lol). Once we enabled revocation checking for that, it fails for any of our certs. And even a number of our internally issued certs chain up to US Treasury which is external.


    Anyhow, working a CA case. Once we get one successful will retry the proxy to public Entrust / US Treas / Others.