By default the TIBCO Mashery SaaS platform does not support SNI for SSL Handshake negotiation for the proxied API request to the customer's backend service. Its only when the customer's backend or proxy is SNI enabled, Mashery needs to adhere to the  SNI enablement in order to make successful SSL Handshake negotiation through SNI enabled stack from mashery for the API requests processed through Mashery to be passed successfully to the customer's SNI enabled backend host.  

Lets  see how the API calls are made to test the SNI requirement before we make the decision to move the customer to SNI stack. 

ANY

We have the ability to test the API request with SNI enabled by directing API traffic through a set of SNI enabled infrastructure in Mashery for testing purposes.

You can test this yourself.  The way you would use this is to replace hostname in the API request URL with "use1.masherytmjsni.api.mashery.com" and to include a "Host" request header with the original API URL hostname.  See example cURL request below:

Original API Request:
curl --location --request POST 'https://api2.masherycustomer.com/test/v2//availabilityquery?api_key={YOUR API KEY HERE}' \
--header 'Authorization: Bearer {YOUR TOKEN HERE}' \
--header 'Content-Type: application/json' \
--data-raw '{"InterventionQuery": {"InterventionFilter": [{"Value": ["INT-0000016410"], "Operator": "is", "Field": "InterventionId"}]}}'

API Request via SNI enabled Mashery worker:
curl --location --request POST 'https://use1.masherytmjsni.api.mashery.com/test/v2/availabilityquery?api_key={YOUR API KEY HERE}' \
--header 'Authorization: Bearer {YOUR TOKEN HERE}' \
--header 'Content-Type: application/json' \
--header 'Host: api2.masherycustomer.com' \
--data-raw '{"InterventionQuery": {"InterventionFilter": [{"Value": ["INT-0000016410"], "Operator": "is", "Field": "InterventionId"}]}}'

TIBCO Mashery has the ability to activate SNI for the customer's Mashery area, but this can only be done for the entire area and not on an endpoint by endpoint level.  This activation is done via a simple DNS change on our side that is a routine type of activation that only takes a few seconds and can be rolled back just as quickly.

Although this change is considered low-risk and has been done successfully for dozens of other customers without an issue, our advice is for customers to identify your unique backend service domain names and select a handful of API calls to test with to ensure that the ssl handshake is successful when using our SNI enabled proxy.  That way, customer will be able to pre-validate any potential impact to API traffic to your backend servers before the activation is made.

You can use the above "API Request via SNI enabled Mashery worker" cURL to model your tests for your other APIs from.  Again, the goal of testing should not be a full functional test, rather it should simply be a test to ensure your API's are responding with 200 responses whether routed through the SNI worker or via the non-SNI Mashery workers that they are today. When you are testing, since the Mashery worker hostname in the request URL will not match the SSL certificate installed, you will get an SSL certificate mis-match warning in your browser and this is okay, you can ignore the certificate mis-match since the goal is to ensure that the API requests are making through to the backend services correctly. Once you have completed your testing, we can schedule the SNI activation for the customer's Mashery area. 

Note: Please advise if incase customer is using Mutual SSL Certificate option for the connection between Mashery and their backend services.  You can identify this by looking at API Control Center in the "Security Settings" page for an endpoint and looking for "Client SSL Certificate" in the System Domain Authentication Type selection box.  If is using the Mutual SSL Certificate option, it will require an additional step on the Mashery side when activating SNI for the customer Mashery instance and support needs to engage Mashery Solution Architect and operations to confirm. 

 

In this article we will learn how to test the API calls and other details to see if the customer needs to be hosted on SNI stack and the process to be followed before moving the customer to SNI stack.