Serverless self-service IoT certificate management - Part 1
Secure communication is a important in IoT systems, where certificates and trust play a vital role. In this post, I explore the foundations of certificate management, including PKI, certificate chains, and trust. Also I introduce a serverless self-service API using Amazon API Gateway and Lambda for an easy way to create certificates. This hands-on approach is great for learning purposes and development environments, production setups however require robust managed solutions.
Published Nov 29, 2024
I have been working with several different IoT solutions over the years. One thing they all have in common is the need for trusted certificates that can be used both to establish connection but also device identities. Devices and servers need to trust each other to establish secure communication, ensure data integrity, and prevent malicious attacks. A important part of this trust is the Public Key Infrastructure (PKI), where certificates and Certificate Authorities (CAs) play vital roles, there is also a need to manage a large amount of certificates in an easy way.
In some project we have been rolling our own internal PKI solution, this does come with complexity and security requirements. In other we have been using SaaS solutions, like DigiCert IoT Trust Manager, AWS IoT Core and Amazon Private CA.
However, when it came to development, and sometime even test environments, it was not uncommon that we used some sort of self signed certificates, with an easy self service portal to create different certificates.
In this post, which is the first part of two, we will introduce some basics around certificates and PKI. We will also start to create the foundations for Serverless API that can be used to create a self-service portal for generation of certificates.
The solution I build in this series of posts is NOT suited for a production setup. This is purely meant for development environments and for learning purpose!In a production environment we need:
* Continuous monitoring and automated renewal of certificates.
* Integration with hardware security modules (HSMs) for key storage.
* Compliance with security standards.For these needs, managed services like AWS Private CA, DigiCert IoT Trust Manager, and Let’s Encrypt are ideal.In this first version of the API we do not using any form of Authorization! This will be added in the next part!
As said, in an IoT system, thousands of devices need to interact with servers, IoT brokers, and each other. Each of these interactions must be secure, meaning:
- Servers must authenticate devices to ensure they’re legitimate.
- Devices must authenticate servers to ensure they’re connecting to a trusted source.
Certificates are therefor issued to servers and devices, creating a chain of trust anchored at a Root CA.
A self-service API for certificate management allows:
- Automation: Devices and servers can request and renew certificates programmatically.
- Scalability: As our IoT environment grows, the API can handle the increasing demand for certificates.
- Learning and Testing: Before adopting a managed service, building your own certificate system helps you understand how PKI works.
What Is a Certificate Authority (CA)?
A CA is a trusted entity responsible for issuing digital certificates. These certificates bind a public key to an identity (e.g., a server, device, or user), enabling trust between entities.
CAs are structured in a hierarchy:
- The ultimate trust anchor.
- Self-signed and highly secure.
- Should never be used to issue end-entity certificates directly.
- Issued and signed by the Root CA.
- Delegates the responsibility of issuing certificates to end entities (e.g., devices and servers).
- Limits the exposure of the Root CA.
- Certificates for servers, IoT devices, or users.
- Issued by an Intermediate CA and used in client-server communication or mutual authentication.
A certificate chain is a sequence of certificates, where each certificate in the chain is signed by the subsequent certificate. It represents the hierarchical relationship between a certificate and its issuer.
A chain can consist of one or several intermediate certificates. In the image above the chain is illustrated with two intermediate CAs.
Grossly simplified the handshake would be
- The server presents its certificate to the client.
- The client validates the server certificate by tracing the chain back to a trusted Root CA in its certificate store. When using a self-signed Root CA you need to ensure the bundle is present in the trust store or included in the connection attempt.
In a scenario when mutual authentication is required, the server performs the same process for the client certificate.
In an IoT setup, it’s common to have one Intermediate CA issuing server certificates (e.g., for IoT brokers), and another Intermediate CA issuing client certificates (e.g., for devices). For a client certificate (signed by one Intermediate CA) to trust a server certificate (signed by a different Intermediate CA), both must:
Be part of the same trust hierarchy.
- Both Intermediate CAs must be signed by the same Root CA.
- The Root CA is the common trust anchor.
Be validated against the chain.
- The client verifies the server’s certificate chain, tracing it back to the Root CA.
- The server verifies the client’s certificate chain similarly.
This setup ensures scalability and separation of responsibilities. The Server Intermediate CA focuses on servers and brokers. The Device Intermediate CA focuses on IoT devices.
Now let's start to implement this self service API. We will build this completely serverless using Amazon API Gateway and Lambda functions, with storage of the certificates in S3 and Certificate Manager. This first part in the blog series will only create the first very basic part of the API, which we will extend in the second part. You can find all of the source code on Serverless-Handbook Self Service IoT Certificate management
We will setup an API Gateway with three endpoints for creating our Root CA, Intermediate CA, and Server cert. Everything will be stored in an S3 bucket, and the server certificate will also be imported to Certificate Manager.
First look at the REST API and the structure.
EndpointMethodDescription
/certificates/rootPOSTCreate a new Root CA./certificates/intermediatePOSTCreate a new Intermediate CA./certificates/serverPOSTCreate a new server certificate.I decided to use separate paths (e.g., /certificates/root, /certificates/intermediate, /certificates/server) rather than a single endpoint with a type parameter (e.g., /certificates with type as input) as I feel this aligns better with REST principles and improves the API’s readability and usability.
It's easier to extend the API, with a new certificate type (e.g., device), as we can create a new path like /certificates/device without impacting existing paths. Separate paths naturally segment resources, reducing the need for filtering on the client side. I feel that retrieving all Root CAs is simpler with GET /certificates/root than GET /certificates?type=root.
First of all, let's deploy the common infrastructure, in this case it's just the S3 bucket, we will add more things in this template later.
Next we can setup the endpoints using SAM and
AWS::Serverless::Api and the three Lambda function backing the API.Our Lambda functions is in Python and we use the cryptography library to create the
certificates, below is the implementation for creating a server certificate. For a full implementation visit Serverless-Handbook Self Service IoT Certificate management.This blog covered everything from certificate chains to validating trust in IoT systems. Building your own self-service API is a good way learn about certificates and PKI. In production, however, always opt for managed solutions that offer automation, compliance, and scalability.
Certificates Are the Foundation of IoT Security
Certificates and CAs ensure secure, authenticated communication in IoT ecosystems.
Certificates and CAs ensure secure, authenticated communication in IoT ecosystems.
The Role of Intermediate CAs
Delegating certificate issuance to Intermediate CAs improves scalability and limits exposure.
Delegating certificate issuance to Intermediate CAs improves scalability and limits exposure.
Trust Is Built on Hierarchies
Trust between devices and servers relies on shared Root CAs and validated certificate chains.
Trust between devices and servers relies on shared Root CAs and validated certificate chains.
Build for Learning, Use Managed Services for Production
While this API is a great learning tool, services like AWS Private CA or Let’s Encrypt are better suited for production.
While this API is a great learning tool, services like AWS Private CA or Let’s Encrypt are better suited for production.
To get the full source code and deploy it your self, visit Serverless-Handbook Self Service IoT Certificate management
As Werner says! Now Go Build!