SSL configuration - The Service is temporarily unavailable

[#1]

Hello, I have configured SSLInfo with following information, Saved the proxy and Deployed. When I call service with Correct KeyStore, Trueststore names, it works perfect. But, If I give another Certificate which is not matched with Server Key, then I get "The Service is temporarily unavailable" and Trace shows error occured at apigee request flow itself and did not reach the Target. Is that general behavior ? if not, what could be the reason. Could you please guide on this ?

Below is my SSL Info configuation and Trace flow Image.

<SSLInfo>
	<Enabled>true</Enabled>
	<ClientAuthEnabled>true</ClientAuthEnabled>
	<KeyStore>myStore</KeyStore>
	<KeyAlias>myStoreAlias</KeyAlias>
	<TrustStore>myStore</TrustStore>
</SSLInfo>

[#2]

Error what i Received.

{"fault": {
   "faultstring": "The Service is temporarily unavailable",
   "detail": {"errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"}
}}

[ozanseymen]

Hi @Kumaresan Sithambaram

Possible to clarify your question a little bit please? Are you questioning the error response message structure, or trace behaviour?

[#4]

@oseymen@apigee.com

Thanks for Reply !! Sorry if i confused my question. It is about Trace. Question is when I configured the right KeyStore name which is same mapped in Server too, then looks fine. But, I tried to do a negative test like gave a Keystore name which is not mapped in Server. that case I get temporarily unavailable error. And also, it did not reach Target Endpoint server(as shown in Trace). what i would expecting though I pass a mismatched certificate to server, it should reach Target Endpoint validate there instead of not to reach Target endpoint as shown the trace. I tried to explain what i am looking. Please let me know if you are looking even more elaborate. thanks for your help.

[ozanseymen]

Hi @Kumaresan Sithambaram

As you already know, TLS handshake happens before a connection is established between the client and the server. You can also imagine it as the pre-requisite for a successful connection. In fact this handshake we are refering to is a protocol in its own right - separate from HTTP. HTTP communication can only start if handshake is successful between two parties, i.e. connection is established.

Apigee Trace utility only "traces" HTTP interaction between Apigee and Target. If TLS handshake fails, there is no connection and therefore no HTTP traffic. It will not visually show you TLS handshake protocol messages as it would be too noisy - you wouldn't want to see that.

Apigee Trace displays the fault on the target endpoint as that endpoint is failing to establish a valid connection to your target. So IMO Apigee behaviour is correct.

Check out this link to read about the internals of the handshake protocol: http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work

[#6]

@oseymen@apigee.com

Thanks for quick response and good explanation. In that case, why do I get "Service is temporarily unavailable" which confused message to End User. Isn't it ? Is that general behavior for this case by Apigee ? If so, is that anyway change the Message more meaningful ?

[ozanseymen]

Hi @Kumaresan Sithambaram

I can't comment on the default Apigee error message but it is always a good practice to modify error responses according to your design and present consistent error responses to clients anyway.

So I'd recommend you catch this error and return a simple 500 - Internal Server Error to your clients.

Check out fault handling for Apigee here http://docs.apigee.com/api-services/content/fault-handling.

Here is another community article on error handling: https://community.apigee.com/content/kbentry/23724/an-error-handling-pattern-for-apigee-proxies.html

[#8]

Hi @oseymen@apigee.com

Thanks !! Sometime back i followed you fault-handling procedure, even i had a question in community on this Thread : https://community.apigee.com/questions/26568/customize-default-fault-format.html#comment-26851

But, this case the fault.name is "ServiceUnavailable" which can be applicable even if really the service unavailable due to other reason also like Server Went Down and etc. But,This case i want to specifically define Service unavailable because of TLS hand shake failed. How to determine the TLS Handshake failed ? Could you please suggest on this ?

I see the system log where internally what's actual problem, but how do i bring this at Edge UI ?

com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender$ResponseListenerForLBTarget$1.onException(LBTargetRequestSender.java:469)
[http-adaptor-1.0.0.jar:na]


        at
com.apigee.protocol.http.HTTPClient$Context.handshakeFailed(HTTPClient.java:1286)
[http-1.0.0.jar:na]


        at
com.apigee.nio.SSLTransport.run(SSLTransport.java:156) [nio-1.0.0.jar:na]


        at
com.apigee.nio.SSLTransport.process(SSLTransport.java:488) [nio-1.0.0.jar:na]


        at
com.apigee.nio.ClientChannel.process(ClientChannel.java:263) [nio-1.0.0.jar:na]


        at
com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:479)
[nio-1.0.0.jar:na]


        at
com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:449)
[nio-1.0.0.jar:na]


        at
com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:16)
[nio-1.0.0.jar:na]


        at
com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:36)
[nio-1.0.0.jar:na]


        at
com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:266) [nio-1.0.0.jar:na]


        at
com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:256) [nio-1.0.0.jar:na]


        at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:16)
[nio-1.0.0.jar:na]


        at
com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:36)
[nio-1.0.0.jar:na]


        at
com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]