SSL Configuration in Microgateway
SSL creates a secure connection between servers and clients over the web and internal network, safeguarding and allowing sensitive data to be securely transmitted. HTTPS (Hypertext Transfer Protocol Secure) is an internet communication protocol that protects the integrity and confidentiality of data between the user's computer and the site. The data sent over HTTPS is secured using TLS, which provides protection using encrypted channel.
A Microgateway instance can be communicating with various other components such as, API Gateway server, native services, clients, and Elasticsearch. You must create secure connections between the Microgateway instance and these components in order to enable a secure channel of communication. This article explains SSL configuration in Microgateway.
The article assumes that you have a running Microgateway instance. Additionally, you must have a basic understanding of the following:
API Gateway server and administration configuration in
API Gateway Java security using keystore and truststore certificates
The figure depicts various scenarios where a truststore is used in Microgateway.
1. Two-way SSL connection with the end user
2. HTTPS connection with the native API
3. HTTPS communication with related servers depending on their usage
This figure depicts various scenarios where a keystore is used in Microgateway.
1. HTTPS connection with an end user
2. HTTPS connection with the native API
Managing Certificates in Microgateway
As Microgateway is expected to be scaled up to many instances, managing certificates is important. Microgateway has its own keystore and truststore to manage its certificates. Certificates are required to implement a trust relationship between API consumers, Microgateways, API Gateways and native (micro) services depending on the scenario in which it is used.
Public Certificates
To expose a trusted endpoint, Microgateway has to expose a certificate that has been signed by a certificate authority (CA). Usually the CA is a global widely trusted authority such as GlobalSign, Let's Encrypt, or GeoTrust. For internal usage, CA can also be established within an organization. Using multi-name certificates (SAN) or wild card certificates allow the reuse of a certificate across multiple domains or servers.
Internal Certificates
For internal certificates, you can establish a private CA. You can manually manage certificates through SSL tooling. For example, you can have Vault from Hashicorp that provides a private CA solution, which can be deployed on-premises. Other CA solutions are offered by cloud vendors such as Amazon.