Problem: Two-way SSL to target server encountered a fatal handshake failure
Symptoms: API calls through Apigee would result in 503. The management server UI trace would show the SSL connection to the target server failed due to fatal handshake failure.
Cause: A recent discovery shows when the property *.override.method is defined within the HTTPTargetConnection block, a two-way SSL handshake failure to the target server is observed. The fatal SSL Handshake Failure alert seems to have occurred at the client certificate verification stage by checking the tcpdump.
For example, below definition would result in SSL Handshake Failure:
<HTTPTargetConnection>
<Properties>
<Property name="GET.override.method">POST</Property>
</Properties>
<LoadBalancer>
<Server name=“server1" />
</LoadBalancer>
<Path>/targetserver/path</Path>
</HTTPTargetConnection>
and the target server ‘server1’ is defined as
{
"host" : “server1.company.com",
"isEnabled" : true,
"name" : “server1",
"port" : 443,
"sSLInfo" : {
"ciphers" : [ ],
"clientAuthEnabled" : true,
"enabled" : true,
"ignoreValidationErrors" : false,
"keyAlias" : “client_keyalias",
"keyStore" : “client_keystore",
"protocols" : [ ],
"trustStore" : “Server1ServerCA"
}
}Workaround: would be to simply comment out the Property line, and redeploy the api proxy bundle:
<HTTPTargetConnection>
<Properties/>
<LoadBalancer>
<Server name=“server1" />
</LoadBalancer>
<Path>/targetserver/path</Path>
</HTTPTargetConnection>The override method can also be done using an AssignMessage policy in the Target Request PostFlow:
<AssignMessage name="AddOverrideMethod">
<Set>
<Headers>
<Header name="X-HTTP-Method-Override">GET</Header>
</Headers>
<Verb>POST</Verb>
</Set>
</AssignMessage>
and:
<Step>
<Name>AddOverrideMethod</Name>
<Condition>request.verb == "GET"</Condition>
</Step>
NOTE: when returning from the target, you DON'T automatically return to the same conditional flow you hit in the request -- the condition is checked again. Whenever you are modifying the request.verb in your proxy, the best practice is to capture request.verb into another variable and check that instead of request.verb.
We are currently looking into the root cause of this issue and it could potentially require a code fix from Apigee. Further update will be available when ready.
LinkedIn
Twitter