Enabling SNI and its side effects?

[#1]

Hello,

We have a use case where we need to access AWS API Gateway via Apigee (Private Cloud 4.15.07). We never enabled SNI in Apigee but it seems AWS requires clients to implement SNI.

I can enable SNI in Apigee to make AWS API work, but I am little wary of how would it affect current upstream and downstream integrations (clients and back-end apis).

Once enabled...

• Does it become a mandate or recommendation?
• Do client applications have to perform some additional work to invoke API proxies over SSL?
• Do backend APIs have to support SNI?

Another side note...

Is it possible to create create multiple Virtual Hosts (same port, different host alias) and use different SSL certs OR is a SSL cert tied to a port in Apigee VH (which implies I need separate port/VH)?

Can you please provide some best practice/guidance on this topic?

Thanks!

[david_ryan]

We are just starting down this road as well with SNI. I've enabled SNI (southbound of mp's) using Apigee's documentation and a few related posts in the community but I cannot seem to get it to work. The target is an Amazon api gateway endpoint. Is there any information regarding your configuration you would be willing to share, specifically your proxy configuration?

Here is my related post with details

https://community.apigee.com/questions/40562/is-there-a-way-to-debug-or-tell-if-southbound-sni.html

Also here is a posting that may answer part of your question above

https://community.apigee.com/content/kbentry/19867/disable-sni-for-select-connections-on-southbound....

[#3]

Hi David.. Thanks for sharing your findings.

It works for me once I enable SNI on MPs. I tested with a AWS API Gateway endpoint that is acting as proxy to SNS. My target endpoint in Apigee proxy looks like this (note that I am using Apigee's TargetServer feature with variables):

<HTTPTargetConnection>
	<LoadBalancer> 
		<Server name="aws.apigateway.api"/> 
	</LoadBalancer> 
	<Path>{subpath}</Path>
</HTTPTargetConnection>

where aws.apigateway.endpoint is something like:

{
  "host": "XXXXXXXX.execute-api.us-XXXX-X.amazonaws.com",
  "isEnabled": true,
  "name": "aws.apigateway.api",
  "port": 443,
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": false,
    "enabled": true,
    "ignoreValidationErrors": false,
    "protocols": []
  }
}

and subpath is something like:

/dev-stage/API_ENDPOINT

Couple of things you may want to check:

1. Restart MPs after enabling SNI.

2. Is the AWS API properly staged? Do you see anything in CloudWatch logs? Note that CloudWatch does not log 503 errors.

Hope that helps!

[david_ryan]

Thanks so much for the reply. Interesting you setup a target server and I wonder, if at all, that makes a difference. The other settings I have specified as well on my target connection. On a related note we're discovering that the MP's support the SSL ciphers and protocols supported by the JDK your running. We've discovered that the AWS api gateway expects:

SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256

What JDK vendor (Orace or openjdk) and version your running with on your MP's? Also what version of OPDK are you using?

[#5]

Those SSL settings are similar for us. We use Private Cloud 4.15.07. We are little behind on Apigee upgrade unfortunately 🙂 We use OpenJDK v1.7 I believe.

[#6]

@Maruti Chand @sudheendra @Divya Achan