Open-source cloud Certificate Authority

We’re excited to announce the open-source release of our serverless Certificate Authority and public Terraform module.

Open-source cloud CA architecture

Why we developed a cloud CA

At Q-Solution, a specialist company providing managed services to UK government, we wished to implement a private CA in AWS to secure a community of government organizations via the public Internet using certificates with mTLS.

We initially looked at AWS Private CA, however each environment, consisting of a Root CA and Issuing CA, and around 100 certs per month, would have cost $10,500 US per year. This was too expensive, especially as we required a number of separate isolated environments for security reasons.

We therefore decided to develop and build our own solution: a serverless CA in AWS with high levels of security, typically costing under $5 per month per environment, around 0.5% of the cost for an equivalent AWS Private CA infrastructure.

Cloud CA Features

Open-source cloud CA example hierarchy

Our serverless CA includes:

• Private keys for Root and Issuing CA stored in AWS KMS, certified to FIPS 140–2 level 3
• 100% serverless infrastructure in AWS for low operational overhead and minimal security updates
• Choice of ECDSA and RSA algorithms
• Automated Certificate Revocation List (CRL) publication
• Optional public CRL Distribution Point (CDP) and Authority Information Access (AIA) locations
• Fine-grained access control configurable using AWS IAM permissions
• Centralized logging and auditing via CloudTrail and CloudWatch logs
• GitOps operating model with no manual processes
• Range of options for requesting and issuing end-user certificates

Cloud CA Architecture

The cloud CA uses completely serverless infrastructure in AWS — see the architecture diagram at the top of this article.

CA private keys are stored in AWS KMS using hardware certified to FIPS 140–2 Level 3. Details of issued certificates are stored in an AWS DynamoDB table, and all actions are logged in AWS CloudTrail and Amazon CloudWatch.

Serverless CA Lambda functions orchestrated by AWS Step Function

An AWS Step Function orchestrates the various Lambda functions for creating the Root CA and Issuing CA, issuing CRLs and end user certificates.

Getting Started

We’ve published a public Terraform module for straightforward installation and configuration of the Cloud CA in your environment.

A full Getting Started guide is on our Docs site, the high level steps are:

• clone the Serverless CA open-source repository
• copy the contents of the examples/default folder from the Serverless CA GitHub repository to your own Terraform repository
• update ca.tf to uncomment the recommended arguments, and update to the latest Terraform provider version, e.g.

module "certificate_authority" {
  source  = "serverless-ca/ca/aws"
  version = "1.0.0"
}

• update backend.tf to point to your own Terraform state file S3 bucket
• ensure that provider.tf includes the required alias for us-east-1
• update locals.tf with CA names appropriate for your organisation

Deploy infrastructure

Deploy the infrastructure to your AWS account:

terraform init
terraform plan
terraform apply

Issue test client and server certificates

Once the infrastructure has deployed, follow the guide to creating test client and server certificates using the cloned repository

python utils/client-cert.py
python utils/server-cert.py

User certificate issued by serverless CA

Certificate Revocation

Certificate revocation is an important feature of any CA system. Revoking a certificate is performed using a GitOps model where details of the certificate to be revoked are added to your serverless CA GitHub repository.

CRL issued by serverless CA every 24 hours

Follow the instructions in the Revocation section of our docs site. After applying Terraform, certificates will be revoked within the next 24 hours. If you need to revoke a certificate immediately, start a new CA Step Function execution from the console.

When setting up the serverless CA for the first time, an important consideration is whether the CRL should be published publicly and a link to the CRL file location included in the CRL Distribution Point (CDP) extension of issued certificates.

If you wish to enable public CRLs and CDPs, details of how to do this are provided in the Revocation section of our docs site. You’ll need to first set up a Route53 Hosted Zone in your AWS account.

CRLs are then published via CloudFront, and CDPs and Authority Information Access (AIA) extensions included in issued certificates. The AIA extension can be used as a straightforward way to download Root CA and Issuing CA certificates.

Configuring AWS services to use serverless CA for mTLS

AWS services supporting mTLS

The Issuing CA and Root CA certificates are published as a bundle, which can be used for upload as a TrustStore when configuring mutual certificate authentication (mTLS) for AWS services such as:

• Amazon API Gateway
• AWS Application Load Balancer
• AWS IAM Roles Anywhere
• Amazon EKS

Example deployment and code

In addition to the examples included within the AWS CA Terraform Module, we’ve published a stand-alone example implementation at github.com/serverless-ca/cloud-ca.

The AWS CA Terraform Module is highly configurable through the use of Terraform variables. Options selected for the example Cloud CA include:

• ECDSA algorithms for CA keys
• Public CRLs, CDP and AIA certificate extensions
• GitOps for CRL publication and Certificate Signing Requests (CSRs)

Example CRLs and CA certificates can be downloaded using HTTP at locations provided in the example Cloud CA README:

• Cloud CA CRL
• Cloud CA Issuing CA certificate
• Cloud CA Root CA certificate

If you choose to use the Cloud CA repository as the basis for your own serverless CA, it’s important that you delete the CSR files and revoked certificate details as detailed in the Cloud CA README.

Cost comparison with AWS Private CA

The monthly AWS cost for the AWS accounts used for the CI/CD GitHub Actions tests of this repository are typically $3 without a hosted zone and CloudFront, and $4 with a hosted zone and CloudFront (below). In our case, we typically issue around 100 certificates per month, resulting from integration tests incorporated to our CI/CD pipeline

Typical monthly cost of open-source cloud CA in AWS

The majority of AWS costs are for the 3 KMS keys per environment.

Taking the upper figure of $4, the yearly cost would therefore be $48, so around $50 per year per CA environment, each CA environment consisting of a Root CA and an Issuing CA.

As of 12 February 2024, pricing of AWS Private CA is $400 per month per general purpose CA, plus $0.75 per certificate.

The monthly cost for a Root CA and Issuing CA plus 100 certificates per month is therefore $875 per month (2 x $400 + 100 x $0.75) or $10,500 per year.

The above cost estimates are provided for guidance only. The actual costs in your environment will depend on usage, and AWS pricing which may change at any time. The author accepts no responsibility if the costs of running your CA prove to be greater than expected.

Security considerations

As detailed on the security section of our Docs site, It’s very important to implement your certificate authority (CA) in a secure way:

• each CA environment should be in a dedicated AWS account
• carefully select CA options for the Terraform module
• use ECDSA algorithms (default) rather than RSA
• don’t make CRL public unless needed (default)
• review other options from a security perspective
• very carefully control AWS IAM principals and permissions
• restrict permissions allowing invocation of all Lambda functions
• store user / device private keys in hardware if possible
• always verify person or entity requesting certificate is authorised
• limit access to CA source code repository and CI/CD pipeline
• ensure updates to CA source code repository are reviewed, especially new Certificate Signing Requests (CSRs)
• monitor CloudTrail for suspicious events, e.g. unauthorised signing using a CA KMS asymmetric key
• export CloudTrail and CloudWatch logs to a central SIEM
• create rules to alert on potential attacks, e.g. CloudTrail event showing CA KMS signing not correlated to Lambda function log in CloudWatch
• update the CA regularly and ensure no vulnerable dependencies
• run regular security scans on CA AWS accounts or link to a CSPM
• consider an independent security review of the CA infrastructure and applications using certificates issued by the CA

Photo by Florian Berger on Unsplash

The security of any CA is dependent on the protection of CA private keys. AWS KMS is used to generate and store the asymmetric key pair for each CA, with no export of the private key allowed. The hardware security modules (HSMs) used by the AWS KMS service are FIPS 140–2 level 3 certified in all AWS commercial regions except China, which uses OSCCA certified HSMs.

Secure operation of AWS services such as KMS rely on AWS upholding its side of the AWS Shared Responsibility Model.

The above information is provided to assist you in assuring the security of your CA. However, the author accepts no responsibility for your CA being implemented and operated in a secure manner.

What’s next?

We’re looking forward to feedback from the community on our open source project and Terraform Module, and to suggestions for additional features, options and further documentation.

Contributions to the project are very welcome, as detailed in the Contributing guide.