Layer7 API Management

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?

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.

Sincerely,

Stephen Hughes

Director, CA Support

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."....so 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?

Chris,

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.

Sincerely,

Stephen Hughes

Director, CA Support

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 endpoint...so 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 CRL...so hopefully won't be an issue.

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

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.