Connecting to a TLS-protected endpoint (OpenTracing) from Apigee Edge

Not applicable

Hi guys,

I'd like to start our OpenTracing trace from Apigee and would need some help.

The goal would be to have visibility on the the time spent in Apigee and also the time between Apigee and our TargetEndpoint.

So here's my options:

  • Use the "JavaScript callout" to directly invoke the OpenTracing NodeJS client
    • Issue: Even with a working JS file, a package.json and all the npm dependancies correctly installed (with this Management API) I still get the following error:
Uncaught ReferenceError: require is not defined
  • Use the "Service Callout" (or the "JavaScript callout" with the httpClient) to send a JSON containing all the information needed to an in-house REST endpoint that would do all the OpenTracing specific work
    • Issue: The REST endpoint is in HTTPS (valid certificate and it's not a self-signed one) and both Service Callout and Javascript's httpClient throw me the following error:
"handshake_failure"

So here's my questions:

  • Does Javascript callouts supports loading (require) module?
  • Why am I receiving an SSL error when I know for a fact that the certificate is valid?
    • I'm not trying to do two-way SSL... just a simple HTTP POST to an endpoint

Best regards 🙂

1 4 806
4 REPLIES 4

Hey - the handshake failure indicates that Apigee Edge is not trusting the CERT that is being presented by the endpoint .

In the ServiceCallout policy, it is possible for you to configure SSL information (via the SSLInfo element) that specifies the trust store. The trust store is the thing that will be referenced when Apigee Edge verifies the target CERT.

As far as I know, it is not possible to configure the HTTP client available in the JavaScript policy to verify Certs that are not signed by a well known root CA, or some other CA that's signed by a well known root. There is an outstanding request for this.

Last bit of information: the Missing require thing -- you will need to browserify npm modules to get them to work in the JavaScript policy in Apigee edge. But in this case I'd recommend that you stick with the ServiceCallout and the SSLInfo and Truststore. Which means you do not need to resolve the missing require problem.

you asked

Why am I receiving an SSL error when I know for a fact that the certificate is valid?

The cert may be "valid" in the sense that it is a real cert, and is not expired, and asserts the hostname that you are trying to reach. But the whole model of site certificates is predicated on the idea of a chain of trust. If the cert is signed by "acme corp", and I don't trust acme corp, then I won't trust the cert. if the cert is signed by "verisign root CA" and I trust "verisign root CA", then I will trust the cert.

Self-signed certs will be treated as Untrusted by Apigee Edge unless you load the cert into the truststore, effectively telling Edge, "you should trust this cert."

Sorry I meant to write "it is not a self signed certificate" in my initial post...

The SSL certificate is signed by a well know root CA (Symantec), it is not expired and everything on the REST endpoint is correctly configured (it has a Grade A using https://www.ssllabs.com)

I found a couple of thread about SNI causing such issue... could it be relevant?

As for browserify, you would suggest that I bundle all the needed dependancies using that instead of using the "package.json + npm install" ?

ah, ok... that changes things.

YES, SNI could be the issue here. Can you verify that the site is using SNI? The way to do it is via the openssl tool. This will get you the "Default" certificate from a site.

openssl s_client -connect sitename.example.com:443<br>

This will get you the cert from a site if you use the SNI client extension:

openssl s_client  -connect sitename.example.com:443 -servername sitename.example.com<br>

If you get *different* certs from those, then the site is using SNI, and it's possible that Edge is not requesting the cert correctly. If you get the same certs from those two commands, then... I don't know the issue. In that case maybe post the cert and we can see if there's something amiss.

Another thing you could do is turn OFF the SSL verification in the endpoint for the ServiceCallout. This is obviously not recommended, but it may satisfy as an interim workaround.

<SSLInfo>
  <Enabled>false</Enabled>
  <IgnoreValidationErrors>true</IgnoreValidationErrors>
</SSLInfo>

For browserify, I would suggest you run it on the module, not on a fully operational nodejs app. If you intend to call into a npm module from a JSC, then browserify is one option to do that.

(But again, I think the JSC won't handle the certs correctly, so, maybe not what you want... )