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.

Managing StrongSwan VPN with

May 24th, 2017 Guide



Cryptography is used to securely communicate between participants. Encrypted data can be sent over insecure connections because it is very hard (practically impossible) to decrypt this data without having a digital secret key.

There are two main types of cryptography:

Shared key cryptography

Also known as as symmetric-key cryptography. Both sides have same, shared key.

Pros: simple.

Cons: Does not allow scenarios of any complexity as trust can not be delegated. No clear way to revoke trust after the key was compromised, one have to explicitly reconfigure peers’ configurations.

Public key cryptography

Also known as asymmetric cryptography. Each side has it’s own key. Such key has two parts: private and public. Private key should never leave the device it was generated on. Private key allows decryption of data that was encrypted for it, using the public part of the key. Public part can be sent over the internet.

Pros: trust can be delegated by signing additional certificates and validating the signature by other participants. Certificates and therefore trust are limited in time and can be revoked. This allows flexibility.

Cons: requires infrastructure

What is VPN?

VPN is a software that secures traffic between two communicating sides. Each side can be a single computer or a computer network. Typical VPN bridges between corporate office network and a laptop of an employee. When connected using VPN, the employee can access office servers that reside inside office network. Typical servers on corporate network are Exchange mail server, file sharing servers, etc. Corporate servers usually not exposed directly to the internet for security reasons. VPN requires both sides to be authenticated and authorized. This is done using usernames and passwords in some cases but cryptographic certificates are believed to be better alternatives.

What is cryptographic certificate?

As mentioned above, information can be encrypted using public part of cryptographic key. How is it possible to determine that the key belongs to whoever it claims to be? That’s what certificates are for. Cryptographic certificate binds two things together: identity (such as and a public key. How one can trust a certificate? That’s what PKI is for.

What is PKI?

Public key infrastructure is a way to work with certificates and ensure trust chains. Trust chain starts at a Certificate Authority (CA), one of many world-wide trusted companies. CA certificates are typically installed on computers (PCs, Macs, servers) during operating system installation. This allows your browser to decide which sites are trusted when surfing to HTTPS sites.

Each CA can be imagined as pyramid’s top. Certificates signed by CA are automatically trusted by the PKI-implementing software. These could be imagined as the pyramid level just below the pyramid’s top. Certificates signed by certificates that are signed by CA are also trusted and so on, till we reach the bottom of the pyramid. Certificates at the bottom are the ones that are used to authenticate sites (Google, Facebook, etc) and less frequently – people. Common height of such pyramids is 2 to 4 levels, including top and bottom.

Current problems

Private CA insecurity

Private, also called “self-signed” CA is yet another pyramid’s top, except in this case, it does not belong to a publicly trusted CA company.

Typical installation of StrongSwan VPN (and some other VPNs) relies on private CA. This CA is used to issue (sign) both VPN server certificate, which is used to authenticate the VPN server and VPN clients’ certificates to authenticate VPN clients.

iOS devices such as iPhone require that the VPN server’s certificate will be a trusted certificate. Trusted in this context means that there is a trust path from any publicly trusted CA (pyramid’s top) to the given certificate. In case of private CA, there will be no publicly trusted CA up the chain. The solution is to install private CA certificate on the device along the trusted public CA certificates.

Installing private CA on a device is dangerous. If private CA certificate is compromised, all encrypted communications of the device can be listened to (decrypted) and tampered with. The exception to this horrible rule is few more security-aware companies which use special techniques to protect themselves and their clients. Compromise of a CA certificate means that fake certificates can be issued for any site the device tries to access, benefiting the attacker and allowing him/her to decrypt and tamper with traffic. Compromise of private CA is more likely to happen as it’s not handled by companies which entire orientation is PKI and security. Such compromise is also more likely to be undetected for longer period of time.


For proper credentials revocation checks, additional setup is required which is sometimes neglected and done in hurry when the first revocation should be done.

How Beame solves VPN certificates management problems

See our video: Gatekeeper managing StrongSwan.

Certificates manager

Beame Gatekeeper with StrongSwan plugin can be used instead of private CA management. In contrast to private CA, certificates issued using Beame Gatekeeper are signed by publicly trusted CA. This means that additional (private) CA certificate is not required to be installed on the iOS device.

Beame Gatekeeper allows to create certificate and VPN settings file for an iOS device. Setting up StrongSwan VPN on an iOS device is now as easy as scanning the QR shown in web administration interface and another few touches on the mobile device.

Beame Gatekeeper updates StrongSwan configuration files once per minute adding cryptographic identities of new users and removing revoked identities. Beame Gatekeeper disconnects any users that are currently connected, whose identities were revoked.


Correct credentials revocation does not require additional effort. Hitting “Revoke” in Beame Gatekeeper’s web administration interface is enough for VPN service reconfiguration.