Can't configure Mutual SSL to target server - unexpected Handshake Failure

Not applicable

I am trying to configure mutual SSL between my Edge environment and my target server. I would like to use the Apigee-provided key and certificate for this, since that's the way mutual SSL should work. I have configured my proxy to use the pre-provided apigee cert in my test environment

    <HTTPTargetConnection>
        <URL>https://backendurl.com/mybackendpath</URL>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>freetrial</KeyStore>
            <KeyAlias>freetrial</KeyAlias>
            <TrustStore>trusty-truststore</TrustStore>
        </SSLInfo>
    </HTTPTargetConnection>

and I created my trusty-truststore containing all the certificates in the response chain from the target server: my own cert and those provided by my cert authority (Comodo), as outlined in your documentation. This works fine until I configure our target server to require the *.apigee.net client certificate, which I downloaded from my browser. As soon as I do this, I get an error on every call, and in the trace console I see

error  		The Service is temporarily unavailable

error.cause  	Received fatal alert: handshake_failure

error.class  	com.apigee.messaging.adaptors.http.HttpAdaptorException

A quick google of this error suggests that the required certificates are not in my truststore, but I can see in the UI that this is not the case. Since I don't have the Apigee private key, I created my own private key / certificate pair, again using Comodo as the root authority, configured my target server to trust it, uploaded it to the test environment and configured my proxy to use this instead. This also did not work, producing the same error. When I run this against the target server from my localhost in openSSL it works fine, which leads me to believe that there is a configuration error on the Apigee side. What could I be doing wrong?

Solved Solved
0 4 1,200
1 ACCEPTED SOLUTION

Not applicable

OK - so this issue is finally resolved. The problem was simply that the *.apigee.net certificate provided as the freetrial key is not the same as the cert provided in your browser when you go to https://myorg.apigee.net.

We opened a support ticket to request that the matching key for the current *.apigee.net certificate chain be loaded in our environment, and once this was done, everything worked fine.

View solution in original post

4 REPLIES 4

Not applicable

I also sumbitted this as case 886271, with the real keystore / truststore names attached.

are you still facing this issue?

try removing,

 <TrustStore>trusty-truststore</TrustStore>

this from SSLInfo and make the call, this is equivalent to running curl with '-k', we could atleast rule out trust store issues

Thanks,

Not applicable

OK - so this issue is finally resolved. The problem was simply that the *.apigee.net certificate provided as the freetrial key is not the same as the cert provided in your browser when you go to https://myorg.apigee.net.

We opened a support ticket to request that the matching key for the current *.apigee.net certificate chain be loaded in our environment, and once this was done, everything worked fine.

Not applicable

I had a similar issue. In my case, I had initially set everything up using self-signed certificates. Once I got the properly-signed certs, I uploaded them into a new truststore. Even though I'd also updated the targetserver definition to use the new truststore, the proxy was throwing 502 responses. I had to undeploy the proxy in that environment and then re-deploy it before it would start working again.

It's weird, though, because I didn't change the proxy at all, just the TargetServer definition that the proxy was referencing.

I'm using a self-hosted Apigee instance, so maybe it's a bug in an older version that doesn't apply to Apigee cloud.