SSL/TLS: Mashery point of view

SSL/TLS: Mashery point of view

book

Article ID: KB0075122

calendar_today

Updated On:

Products Versions
TIBCO Cloud API Management -

Description

Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL) are the protocols that provide communications security over a computer network. TLS and SSL are together known as "SSL". SSL relies on Certificate Authorities as a part of Public Key Infrastructure in order to verify the identity of the server host. Client applications, such as a web browser, rely on root certificates installed locally, either packaged with the operating system or with the application itself. Verification of host identity requires that the client can verify the digital signature of the Certificate Authority against the root certificates available to it.  Additionally, the certificate must not have been expired or revoked and must have a Common Name that matches the fully qualified domain name that the client has used to call the host.

Issue/Introduction

Secure Socket Layer is the de facto standard for secure communications on the Internet, particularly for HTTP and REST APIs. This article will provide an outline of how Mashery implements the SSL/TLS security.

Resolution

Mashery Implementation: 

Mashery allows two types of certificate hosting for providing a secure connection.

a) Front end SSL: 
  1. In this type of hosting, Mashery installs SSL certificates on behalf of customers to facilitate encrypted communication between the client and the Mashery Traffic Manager.  This is the most common usage of SSL on the Enterprise platform.
  2. SSL certificates are installed on Elastic Load Balancers.  Only one certificate can be installed per ELB.  A single host (ex. api.customer.com) might be aliased to a logical cluster of several discrete ELB hosts, but these can be considered to be part of the same logical balancer and must have the same certificate installed.
  3. Some certificates require intermediate certificates to be installed in order to be properly verified.  It is the responsibility of the customer to provide all the required certificates with proper private key.
  4. Standard X.509 certificates support the verification of a single FQDN defined in the Common Name of the Subject fields.  Supporting more than one FQDN with a single certificate requires either a wildcard Common Name (ex. *.customer.com) or configuration of Subject Alternative Name field.
b) Mutual SSL:
  1. SSL can be enabled for communications between the Mashery Traffic Manager and the customer's backend API origin server.
  2. In this case, the Traffic Manager acts as the client.
  3. The customer's backend origin server must have a valid SSL certificate installed in order for the Mashery Traffic Manager to verify the certificate.
  4. For the mutual SSL to work the customer need to provide the certificate and key to Mashery. This certificate will be hosted at the Traffic Manager level and will secure the connection between Mashery proxy and customer's API origin server.
Tools that can be used for verifying domains, certificates and keys:
  1. openssl
  2. web browsers (Firefox, Chrome, Safari, etc)
  3. dig
  4. SSL Labs (slow, but thorough)
  5. SSL Shopper (quick, good for verifying certificate chains)
Powered by Wolken Software