Skip to content

DNS & SSL

As a web-based application, Kensium POS relies upon DNS and SSL to ensure that access to the application and its data is over a secure connection.

A strategy for DNS and SSL - and network access in general - must be determined for every client that runs POS, and this strategy will depend upon whether the client can run the recommended Docker-based installation, or if a manual approach is required.

Docker Deployment

Kensium provides an automated, standard way to manage DNS and SSL when it is deployed through a Docker container.

Automated DNS/SSL

When using the standard approach, Kensium manages the DNS name and required SSL certificates through automated scripts. This is the recommended approach for all Docker-based POS deployments.

With this approach, POS is deployed to a subdomain of the *.kensiumpos.com domain. The subdomain is the Organization ID designated during early implementation planning.

The client's Corporate server is deployed at the subdomain host, and individual stores are designated as hostnames off the subdomain. Given an example client where the Organization ID is client1:

  • The client's subdomain would be client1.kensiumpos.com.
  • The client's Corporate Server is accessible at client1.kensiumpos.com (the root of the subdomain).
  • Individual stores would have hostnames based on their location (naming can be discussed with the client), e.g.:
  • chicago.client1.kensiumpos.com
  • dallas.client1.kensiumpos.com

Note

We can use manual DNS and SSL configuration if a client does not want to use the kensiumpos.com name for their POS services. See the next section.

Configuring the Automated Approach

The DNS and SSL configuration is automated using two separate shell scripts which will be a part of deployment package which we are pushing to s3 bucket.

The process is divided into two independent responsibilities:

  1. A DNS Script that creates the required Cloudflare DNS records.
  2. An SSL/PFX Script that provisions the Let's Encrypt SSL certificate and creates the PFX file required for SSL.

Note that the Cloudflare API token is not stored in the .env.docker (environment variables) file. The script prompts the user to enter the Cloudflare API token during execution. The token is used only for the current execution and is unset/removed when the script finishes.

Warning

Several environment variables must be configured before running these scripts; see Environment variables for more information.

DNS Script

The manage_dns.sh script is responsible for creating the required DNS records in Cloudflare. The script uses the configuration provided in the environment file to determine:

  • Client domain
  • Cloudflare Zone ID
  • DNS configuration

The Cloudflare API token is requested interactively when the script is executed.

The commands to run the the script are:

1
2
chmod +x manage_dns.sh
./manage_dns.sh <name of env file>
The script will prompt the user to enter the Cloudflare API token to create the DNS entry and perform related configuration.

SSL / PFX Script

The manage_dns_ssl.sh script is responsible for:

  • Checking the required SSL tools.
  • Requesting the Cloudflare API token interactively.
  • Using Cloudflare DNS authentication for Let's Encrypt.
  • Creating/provisioning the Let's Encrypt certificate.
  • Validating the generated certificate.
  • Creating a PFX file from the certificate.
  • Storing the PFX file in the configured certificate directory.
  • SSL/PFX Flow

The generated PFX is stored under the /home/kenadmin/certs/ folder in the Docker container.

The commands to run the the script are:

1
2
chmod +x manage_dns_ssl.sh
./manage_ssl.sh <name of env file>
The script will prompt the user to enter the Cloudflare API token to configure SSL.

Manual Approach

TODO manually apply PFX certificate to Docker container