Serverless self-service IoT certificate management - Part 1.

2024-11-27
This post cover image
Voice provided by Amazon Polly

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.

Why Build a Self-Service API?

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.

Overview of Certificates, CAs, and Trust

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:

Root CA

  • The ultimate trust anchor.
  • Self-signed and highly secure.
  • Should never be used to issue end-entity certificates directly.

Intermediate CA

  • 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.

End-Entity, leaf, Certificates

  • Certificates for servers, IoT devices, or users.
  • Issued by an Intermediate CA and used in client-server communication or mutual authentication.

Certificate Chains and Trust

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.

Image showing a certificate chain

A chain can consist of one or several intermediate certificates. In the image above the chain is illustrated with two intermediate CAs.

During a TLS handshake

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.

Trust across several Intermediate CAs

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.

Implementation

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

Image showing a API Overview

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.

REST API

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.

Common infrastructure

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.

AWSTemplateFormatVersion: "2010-09-09"
Transform: "AWS::Serverless-2016-10-31"
Description: Certificate Self Service Common Infrastructure
Parameters:
ApplicationName:
Type: String
Description: Name of owning application
Default: image-moderation

Resources:
StorageBucket:
Type: AWS::S3::Bucket
DeletionPolicy: Retain
UpdateReplacePolicy: Retain
Properties:
BucketName: !Sub ${ApplicationName}-storage-bucket

Outputs:
StorageBucketName:
Description: The name of the certificate bucket
Value: !Ref StorageBucket
Export:
Name: !Sub ${AWS::StackName}:certificate-bucket-name

Next we can setup the endpoints using SAM and AWS::Serverless::Api and the three Lambda function backing the API.

AWSTemplateFormatVersion: "2010-09-09"
Transform: "AWS::Serverless-2016-10-31"
Description: Create the API for self service certificate management
Parameters:
ApplicationName:
Type: String
Description: Name of owning application
CommonInfraStackName:
Type: String
Description: The name of the common stack that contains the EventBridge Bus and more

Globals:
Function:
Timeout: 30
MemorySize: 2048
Runtime: python3.12
Environment:
Variables:
CERTIFICATE_BUCKET_NAME:
Fn::ImportValue: !Sub "${CommonInfraStackName}:certificate-bucket-name"

Resources:
LambdaGenerateRootCA:
Type: AWS::Serverless::Function
Properties:
CodeUri: Lambda/API/GenerateRootCA
Handler: handler.handler
Policies:
- S3FullAccessPolicy:
BucketName:
Fn::ImportValue: !Sub "${CommonInfraStackName}:certificate-bucket-name"
Events:
CreateRootCAApi:
Type: Api
Properties:
Path: /certificates/root
Method: post
RestApiId: !Ref GenerateCertificatesApi

LambdaGenerateIntermediateCA:
Type: AWS::Serverless::Function
Properties:
CodeUri: Lambda/API/GenerateIntermediateCA
Handler: handler.handler
Policies:
- S3FullAccessPolicy:
BucketName:
Fn::ImportValue: !Sub "${CommonInfraStackName}:certificate-bucket-name"
Events:
CreateIntermediateCAApi:
Type: Api
Properties:
Path: /certificates/intermediate
Method: post
RestApiId: !Ref GenerateCertificatesApi

LambdaGenerateDeviceCertificate:
Type: AWS::Serverless::Function
Properties:
CodeUri: Lambda/API/GenerateDeviceCert
Handler: handler.handler
Policies:
- S3FullAccessPolicy:
BucketName:
Fn::ImportValue: !Sub "${CommonInfraStackName}:certificate-bucket-name"

LambdaGenerateServerCertificate:
Type: AWS::Serverless::Function
Properties:
CodeUri: Lambda/API/GenerateServerCert
Handler: handler.handler
Policies:
- S3FullAccessPolicy:
BucketName:
Fn::ImportValue: !Sub "${CommonInfraStackName}:certificate-bucket-name"
- Version: "2012-10-17"
Statement:
Action:
- acm:*
Effect: Allow
Resource: "*"
Events:
CreateServerCAApi:
Type: Api
Properties:
Path: /certificates/server
Method: post
RestApiId: !Ref GenerateCertificatesApi

GenerateCertificatesApi:
Type: AWS::Serverless::Api
Properties:
Description: API for creating and managing certificates
Name: !Sub ${ApplicationName}-api
StageName: prod
OpenApiVersion: '3.0.1'
AlwaysDeploy: true
EndpointConfiguration: REGIONAL

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.

import boto3
from cryptography import x509
from cryptography.x509.oid import NameOID
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import serialization, hashes
import datetime
import os
import json

s3_client = boto3.client("s3")
acm_client = boto3.client("acm")


def create_server_certificate(
intermediate_private_key_pem,
intermediate_cert_pem,
fqdn,
country,
state,
organization,
validity_days,
):
# Load Intermediate CA private key and certificate
intermediate_private_key = serialization.load_pem_private_key(
intermediate_private_key_pem, password=None
)
intermediate_cert = x509.load_pem_x509_certificate(intermediate_cert_pem)

# Generate a private key for the server certificate
server_private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
server_private_key_pem = server_private_key.private_bytes(
encoding=serialization.Encoding.PEM,
format=serialization.PrivateFormat.PKCS8,
encryption_algorithm=serialization.NoEncryption(),
)

subject = x509.Name(
[
x509.NameAttribute(NameOID.COUNTRY_NAME, country),
x509.NameAttribute(NameOID.STATE_OR_PROVINCE_NAME, state),
x509.NameAttribute(NameOID.ORGANIZATION_NAME, organization),
x509.NameAttribute(NameOID.COMMON_NAME, fqdn),
]
)
server_certificate = (
x509.CertificateBuilder()
.subject_name(subject)
.issuer_name(intermediate_cert.subject) # Signed by Intermediate CA
.public_key(server_private_key.public_key())
.serial_number(x509.random_serial_number())
.not_valid_before(datetime.datetime.now(datetime.timezone.utc))
.not_valid_after(
datetime.datetime.now(datetime.timezone.utc) + datetime.timedelta(days=validity_days)
)
.add_extension(
x509.SubjectAlternativeName([x509.DNSName(fqdn)]),
critical=False,
)
.add_extension(
x509.BasicConstraints(ca=False, path_length=None),
critical=True,
)
.add_extension(
x509.KeyUsage(
digital_signature=True,
key_encipherment=True,
key_cert_sign=False,
crl_sign=False,
content_commitment=False,
data_encipherment=False,
encipher_only=False,
decipher_only=False,
key_agreement=False,
),
critical=True,
)
.sign(intermediate_private_key, hashes.SHA256())
)
server_cert_pem = server_certificate.public_bytes(serialization.Encoding.PEM)

return server_private_key_pem, server_cert_pem


def handler(event, context):

body = json.loads(event["body"])

bucket_name = os.environ.get("CERTIFICATE_BUCKET_NAME")

# Fetch Intermediate CA private key and certificate from S3
intermediate_private_key = s3_client.get_object(
Bucket=bucket_name, Key="intermediate_ca/private_key.pem"
)["Body"].read()

intermediate_cert = s3_client.get_object(
Bucket=bucket_name, Key="intermediate_ca/certificate.pem"
)["Body"].read()

# Fetch the certificate chain from S3
cert_chain_pem = s3_client.get_object(
Bucket=bucket_name, Key="intermediate_ca/certificate_chain.pem"
)["Body"].read()

# Create Server Certificate
server_private_key_pem, server_cert_pem = create_server_certificate(
intermediate_private_key,
intermediate_cert,
body["fqdn"],
body["country"],
body["state"],
body["organization"],
body["validity_days"],
)

s3_folder = f"server_certificates/{body["fqdn"]}/"

# Upload Server Certificate, Private Key to S3
s3_client.put_object(
Bucket=bucket_name,
Key=f"{s3_folder}private_key.pem",
Body=server_private_key_pem,
)
s3_client.put_object(
Bucket=bucket_name, Key=f"{s3_folder}certificate.pem", Body=server_cert_pem
)

# Import the certificate to ACM
response = acm_client.import_certificate(
Certificate=server_cert_pem,
PrivateKey=server_private_key_pem,
CertificateChain=cert_chain_pem,
)

return {
"statusCode": 200,
"body": json.dumps(
{
"message": "Server certificate created, uploaded to S3, and imported to ACM.",
"fqdn": body["fqdn"],
"s3_folder": s3_folder,
"acm_certificate_arn": response["CertificateArn"],
}
),
}

Conclusion

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.

The Role of Intermediate CAs
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.

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.

To get the full source code and deploy it your self, visit Serverless-Handbook Self Service IoT Certificate management

Final Words

Don't forget to follow me on LinkedIn and X for more content, and read rest of my Blogs

As Werner says! Now Go Build!


Post Quiz

Test what you just learned by doing this five question quiz - https://kvist.ai/998016.
Scan the QR code below or click the link above.

Powered by kvist.ai your AI generated quiz solution!