Using green certificates for your web applications

June 29th, 2017 Guide


This post is intended to anyone, that somewhat concerned about communication security, has basic understanding of why web applications are called so, what cloud is, and how to distinguish between X.509 and  birth certificate to the level, that it is possible to say what each of these is good for.

First of all: HTTP should disappear. I hope this does not sound as an overstatement. Sending unprotected data over the Internet today, at least for people that care, is simply irresponsible.  Connecting parties should recognize each other, and be sure, that only they can peer into whatever they send. And no doubt, the technology is out there, just waiting to be used. Internet browsers do splendid work filtering unfaithful resources. Communities work hard to investigate holes in web applications security techniques and publish their study for anyone who’s interested.

Now, we live in a time, when everything moves into a cloud, so is all that safe if one accesses web application over HTTPS (the secure version of HTTP)? What can happen behind the scenes that will make the connection as unprotected as if it was an outdated HTTP? How easy it can be getting a certificate to run your own web app through securely? Let’s start from going through web app architecture and see.

TLS termination

The very base of secure communication, cryptography is used to change the data in a way, that only use of particular secret key makes it meaningful.

To secure communication between web browsers and web servers, all involved parties use low level protocol called TLS (Transport Layer Security, successor of broken SSL), that performs all cryptography tasks. Browsers indicate TLS protected resource by displaying a green lock to the left of site address:

When implementing TLS traffic encryption between client (for example web browser) and server (e.g. web server), one might assume that “end-to-end” encryption would be between the client and the server. In real life it’s rarely so. Common infrastructure layouts include terminating TLS traffic (opening the encryption) from the client (your web browser for example) before it reaches the servers it was destined for.

In addition web and/or application servers can have encrypted or unencrypted connections to databases and other backhaul services. We will omit these connections for the sake of simplicity.

“Application” in our case means software that implements some logic. Application gets a request, processes it in some meaningful way and sends back a response.

TLS termination at the load balancer

Here is one very common TLS termination layout: TLS is terminated at load balancer. The encrypted traffic starts in the browser and ends inside the load balancer provided by one of Amazon Web Services (Elastic Load Balancing), Google Cloud Platform (Google Cloud Load Balancing) , Microsoft Azure (Application Gateway), or other cloud providers. The traffic is not encrypted between the load balancer and the server that handles the request:

The cloud provider might choose to encrypt the traffic anyway in a transparent way.

NSA-like folks would probably target the traffic from load balancer to the servers as it is the most convenient point to sniff. Even if it’s encrypted, breaking this encryption would be a worthy target.

TLS termination on web+application server

Less common cloud-based layout – TLS is terminated on the servers that respond to requests. Compared to TLS termination at load balancer, this layout requires a bit more architecture related efforts, since deploying and updating the X.509 certificates happens on all of the servers (see image below) instead of one place – the load balancer.

TLS termination on web server, HTTP traffic to application server

Another possible configuration: encrypted traffic up to web server while the latter uses HTTP to talk to the applications.

Simple / home server

The simplest configuration: single server. This might be your server at home. This configuration is not common in the cloud as it has no redundancy.

HTTP(S) server and application server

Web servers usually have two well-formed components.

In some configurations these components run in the same process:

In other configurations they are separate processes:

When terminating TLS on the server, it will usually be in the network processing components of your server: NodeJS, Apache, Nginx, etc.

Why use certificates?

Getting a public x.509 certificate can be challenging. Getting it along with connectivity is twice as appealing. built a line of products, that does exactly that: easy getting a x.509 certs (while keys are generated on the device) and make their CNs (common name from the cert) routable (resolvable in DNS).

If you use one of the products to obtain certificates and you have decided to terminate TLS on the server (your own application, Nginx, Apache), here are the instructions for using Beame certificates on some common platforms.

Exporting Beame certificates

To proceed with following instructions, keep in mind, that all occurrences of $FQDN below are to be replaced with the FQDN that corresponds to your certificate. And $DIR should be replaced with the actual accessible directory.

To get hold of your first public X.509 certificate (you can create more certificates using the one you already own, considering that it is a cert), you should install one of the Beame products. And beame-insta-ssl is the most easy way to do so :

npm -g install beame-insta-ssl

Register to get a token and proceed with simple instructions in registration email.

Eventually it doesn’t matter which product you used to get a certificate, beame-insta-ssl will be able to export the credential to a specified directory (just like e.g. Beame Gatekeeper will do it):

Now lets use it!

Below I placed two examples, of how to implement actual HTTPS server with common tools, using freshly exported credentials (certificates and keys).


Nginx tools

There are Beame tools that will allow, along with certificate management, building many things, from simple TLS tunnels, to real network with authenticated access.

I will not put the detailed description here, just because it is well presented on product pages.

Considering that tools are open-source, you also can peer into and mess with the code.

Recent Posts

Private cloud is easy

PKI based identity on a blockchain

Insta-SSL as a simple way to use RDP / VNC / SSH into LANs

VMs, Docker and vs NSA

x.509 based identity, OS level or dedicated application?