Providing Client Auth =false in SSL info results in error

Google Cloud Apigee
1

I’m setting up 2-way ssl from the apigee proxy (on Apigee hosted Edge) to my back-end service, and uploaded the keystore, and truststore. I’m now configuring the proxy to use client authentication - but my back-end service isn’t locked down yet, so I’m configuring the proxy so I can enable it once the back-end server is updated.

I added in:

<SSLInfo>
            <Enabled>true</Enabled>  
           <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>devKeystore</KeyStore>            
	    <KeyAlias>devKey</KeyAlias>            
            <TrustStore>devTrustStore</TrustStore>  
</SSLInfo>

(yes the keystore, alias, and truststore shouldn’t be named ‘dev…’ but bear with me)

When I submit this, I get a wonderfully generic error:

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

even changing the ClientAuthEnabled to ‘false’ gives the same error - if I comment out all besides ‘Enabled’, it results in successful processing.

My questions:

  • shouldn’t the error give me something at least a little better to diagnose what’s going on?

  • what’s the point of having a client auth enabled flag if there’s no difference between the behavior of true and false

  • even if set to true - if the underlying service doesn’t ask for it - what’s the harm in presenting it?

2

Running a trace provides the same generic info:

error.cause.cause error type state error.class error.cause Identifier

#### Properties
General SSLEngine problem
The Service is temporarily unavailable
ErrorPoint
TARGET_REQ_FLOW
com.apigee.messaging.adaptors.http.HttpAdaptorException
General SSLEngine problem
fault
3

@Daniel Greene I believe the ssl handshake is failing which is resulting in the error. You need to make sure that you have added the correct certificates and keys in the keystore/truststore. I answered a similar question about setting up 2-way ssl here:

Please refer to that and let me know,if it helps.

4

your error suggests ssl handshake failure and the description you provide suggest there could be problem with your truststore

can you try removing the truststore [this is similar to ‘curl -k’], if this works you rule out truststore issues [might have to do with ca cert chains]

<SSLInfo><Enabled>true</Enabled><ClientAuthEnabled>true</ClientAuthEnabled><KeyStore>devKeystore</KeyStore><KeyAlias>devKey</KeyAlias></SSLInfo>
1 Like
5

Removing the element did the trick on this (it’s at least not failing - once the server is configured to be looking for client certs, we can jump off that bridge if needed). I think that the information around 2-way SSL mixes the server SSL parts (Enabled and TrustStore) and the client certificate part (ClientAuthEnabled, KeyStore, KeyAlias).