Today, TLS, or transport layer security, is a modern pillar supporting the underlying communication between devices over the internet. If you’ve visited any current website, chances are you’re exchanging packets through the TLS protocol.
In this blog, I’ll take you through the end-to-end process of generating a self-signed certificate and launching an instance of the Gateway to protect your data in flight with TLS! We will use host-based routing through and add TLS to an existing service!
Figure 1: Leveraging an API Gateway in diagram (2) allows you to configure security, such as TLS, at the Gateway level to protect your services.
Prerequisites
This guide is written for OSX; however, it is applicable for any linux/unix – based distro, assuming you have the following prerequisites installed:
docker-compose
openssl
git
vi
Suppose we are developing on localhost, and I want to generate a wildcard certificate encompassing *.localhost. It’s not possible to issue wildcard certificates for top-level domains referenced here. Thus, today, we will create a wildcard certificate for a subdomain of localhost, for example, *..localhost.
First, we need to edit our /etc/hosts file to use DNS resolution to map some hostnames to an IP address:
When we navigate to https://dashboard..localhost/, our browser will know that this domain resolves to 127.0.0.1! You’ll notice that we get an error ERR_CONNECTION_REFUSED.This is because we don’t have a service running on this IP, so let’s remedy that.
Let’s begin generating a self-signed certificate for *..localhost. First, we need to generate our own SSL certificate authority. From ssl.com, a certificate authority is an organization that validates identities and binds them to cryptographic key pairs with digital certificates.
With our private key generated, we can use the following command to create a root certificate CA.pem. This root certificate allows us to sign subsequent certificates that our browser will trust.
From here, we will populate a configuration extfile .local.ext with the necessary DNS alt_names. We will explicitly list the DNS records for which we wish to have the certificate valid and the wildcard entry with DNS.5 = *..local. DNS.6 and DNS.7 are necessary since we will use Docker networking to communicate between containers. See the following for an example extfile:
With a CA, CA private key, and a subsequent private key for our SSL certificate, we can now generate and sign a new SSL certificate using our root certificate:
# Ensure you obtained or created the .local.ext fileopenssl x509 \ -req \ -in ./.local.csr \ -CA ./CA.pem \ -CAkey ./CA.key \ -CAcreateserial \ -out ./.local.crt \ -days 825 \ -sha256 \ -extfile ./.local.ext \ -passin pass:topsecretpassword
The final step is adding the Root CA CA.pem to our local trust store so that our operating system knows to trust the certificate we just generated.
# Add CA to Keychain# You will be prompted for system passwordsudo security add-trusted-cert \ -d \ -r trustRoot \ -k /Library/Keychains/System.keychain \ ./CA.pem
Now that we have our certificates, let’s use them to secure services in our local development environment! What better way to do this than an API gateway? is a lightweight API Gateway that allows you to add features such as authentication, authorization, access control, and much more to your services so you can focus on building decoupled and scalable services. Let’s pull in an example repository containing all the stack components.
Let’s navigate into the newly cloned repository and ensure we instruct to launch in TLS mode and supply the location(s) of the SSL certificates + private key we just generated. For documentation on TLS and SSL for , please find the documentation here.
cd -pro-docker-democp .env.example .env# Ensure you populate the .env file with a dashboard licence
Edit the ./confs/.env and ensure the environment variables are configured. These options enable SSL for the -Gateway, and instruct it to look for the SSL certificate and corresponding private key in the /etc/certs/ directory.
Assuming we are still in the -pro-docker-demo directory, create a directory ./volumes/certs and copy over the SSL certificate .local.crt and private key .local.key. We will ultimately create a shared volume between our host machine and the -Gateway and -Dashboard containers from which they can read. Here is a docker-compose.yml containing the respective volume mounts and an additional port mapping for a service we will secure with TLS.
Now we can launch the stack with a simple one-liner command:
docker-compose up
You can now visit https://dashboard..localhost to visit the -Dashboard in https mode! Let’s take a breather and summarise what we’ve done so far:
Generate a Root CA, as well as an associated Root Certificate
Generate a local Certificate
Spin up the stack with TLS enabled
We have all the components configured, so now we can serve application(s) through with HTTPS enabled! We must create an API definition within reverse proxying to our service to do this!