Skip to content
Lafunder Tech

Services

Writing, 24 October 2026

Mutual TLS for a kiosk fleet

How a fleet of self-service kiosks proves which device is calling, using a certificate per kiosk, CloudFront, API Gateway and ACM.

The problem with a kiosk on a street corner

A self-service kiosk in a shop or a station is a computer that anyone can stand in front of. It talks to a platform in the cloud all day, and that platform has to answer one question before it does anything else: is this request really coming from one of our kiosks?

An API key does not answer it well. A key is a shared secret. Copy it off one machine and every request made with it looks genuine, from anywhere. For a fleet of kiosks in financial services, the platform needs to know which device is calling, and it needs that proof to be hard to lift.

What mutual TLS changes

In ordinary TLS only the server proves who it is. In mutual TLS the client does too: it presents its own certificate during the handshake, and the connection is refused if that certificate was not issued by an authority the server trusts. The check happens before a single request reaches the application.

For a kiosk fleet that means each device carries its own certificate and private key. A device that cannot present one never gets a connection. A device that is lost or retired is cut off by revoking its certificate, without touching any of the others.

How the pieces fit on AWS

In this build each kiosk carries its own certificate, made with OpenSSL, and mutual TLS runs across CloudFront, API Gateway and ACM. In a setup like this, the gateway checks each client certificate against the certificate authority it trusts and ACM looks after the server certificates, so only traffic that passes the check reaches the platform. The platform itself runs on Amazon EKS.

The platform is deployed with Helm charts through GitHub Actions, so every release goes out the same way, and logs feed CloudWatch, with Lambda and SNS turning the events that matter into alerts. A device that starts failing its handshake is something a person hears about, not something found in a log a week later.

What to plan for

  • Certificates expire. Rotation has to be planned before the first one is installed, not after the first outage.
  • Revocation is the point of the exercise, so the process for cutting off one device should be written down and tested.
  • The private key is the identity. It should never leave the device it was made for.
  • Monitoring the handshake failures is as important as monitoring the application errors.

The result is a fleet where the platform knows exactly which machine is speaking, and a copied secret is worth nothing. The full system is on our Work page.

All writing

Talk to us

Close

Send a brief

This form opens soon. Until then, send the same details by email and we reply from there.

techlafunder@gmail.com

Book a call

Open the booking page (opens Cal.com in a new tab)

WhatsApp or email

Prefer to write first? Either of these reaches the people who would do the work.

WhatsApp
+92 328 4114902Open WhatsApp
Email
techlafunder@gmail.comWrite an email