Automating TLS Certificate Management: From Let’s Encrypt to AWS ACM and Private PKI

Manually managing TLS certificates does not scale well.

The traditional process involves generating private keys, creating Certificate Signing Requests (CSRs), submitting them to a Certificate Authority (CA), validating the request, installing the resulting certificate, monitoring expiration dates, and eventually repeating the entire process.

Modern certificate-management platforms automate much of this lifecycle.

Let’s look at how this works and some of the tools available—including a simple Terraform example using AWS Certificate Manager (ACM).

---

Q: What Does Certificate Automation Actually Automate?

A traditional certificate issuance process might look like this:

Server / Workload
      │
      ├── Generate Private Key
      │
      ├── Generate Public Key
      │
      └── Create CSR
               │
               ▼
        Certificate Authority
               │
        Validate Request
               │
        Sign Certificate
               │
               ▼
           Certificate
               │
               ▼
        Install on Server
               │
               ▼
        Monitor Expiration
               │
               ▼
             Renew

Historically, several of these steps might involve administrators and manual processes.

Modern certificate-management systems can automate nearly the entire lifecycle:

Request Certificate
        │
        ▼
Validate Identity / Domain
        │
        ▼
Issue Certificate
        │
        ▼
Deploy Certificate
        │
        ▼
Monitor Certificate
        │
        ▼
Automatic Renewal

This is generally referred to as certificate lifecycle management.

---

Q: What Tools Can Automate Certificate Management?

There are many options depending on whether you need public server certificates or private enterprise certificates.

Tool / Platform	Common Use	PKI Type
Let’s Encrypt	Internet-facing TLS certificates	Public CA
Certbot	Automating Let’s Encrypt certificates	Public
AWS Certificate Manager (ACM)	AWS TLS certificates	Public / managed
AWS Private CA	Enterprise private certificates	Private CA
HashiCorp Vault PKI	Dynamic workload certificates	Private PKI
cert-manager	Kubernetes certificate automation	Public / Private
Smallstep step-ca	Automated internal PKI	Private PKI
Microsoft AD CS	Enterprise machine/user certificates	Private PKI

The right tool depends largely on what identity the certificate represents and where the certificate will be used.

---

Q: How Does Let’s Encrypt Automate Certificates?

Let’s Encrypt introduced certificate automation to a huge portion of the public Internet through the ACME protocol — Automatic Certificate Management Environment.

An ACME client such as Certbot communicates with Let’s Encrypt.

The basic process is:

Web Server
     │
     ▼
ACME Client
     │
     │ Certificate Request
     ▼
Let's Encrypt
     │
     ├── Verify Domain Ownership
     │
     ├── Sign Certificate
     │
     ▼
ACME Client
     │
     ├── Install Certificate
     │
     └── Renew Automatically

Domain control can be demonstrated through mechanisms such as DNS or HTTP challenges.

The important idea is that the CA no longer needs a human administrator to manually process every certificate request.

---

Q: What About AWS Certificate Manager?

AWS provides AWS Certificate Manager (ACM) for provisioning and managing TLS certificates used with AWS services.

A common architecture might be:

Internet
    │
    │ HTTPS
    ▼
Application Load Balancer
    │
    │ ACM Certificate
    ▼
Application

ACM certificates can also be used with services such as CloudFront and API Gateway.

ACM handles much of the certificate lifecycle, including managed renewal for eligible ACM-issued certificates.

---

Q: Do I Have to Manually Generate the CSR When Using ACM?

Usually, no for an ACM-issued public certificate.

This is one of the important differences between traditional PKI workflows and a managed certificate service.

With traditional PKI you might perform:

openssl genrsa
      ↓
openssl req
      ↓
CSR
      ↓
Submit CSR to CA

With an ACM-issued certificate, you instead request the certificate through AWS:

Terraform / AWS API
        │
        ▼
       ACM
        │
        ├── Certificate request
        ├── Domain validation
        ├── Certificate issuance
        └── Managed renewal

AWS manages the underlying key material for ACM-issued certificates used with integrated AWS services.

---

Q: Can We Automate ACM Using Terraform?

Yes.

Terraform makes the certificate request part of your infrastructure-as-code deployment.

A minimal example looks like this:

resource "aws_acm_certificate" "api_certificate" {

  domain_name = "api.example.com"

  validation_method = "DNS"

  lifecycle {
    create_before_destroy = true
  }
}

Terraform requests an ACM certificate for:

api.example.com

and specifies DNS validation.

However, the certificate will not become usable until domain ownership has been validated.

---

Q: Can Terraform Automate the DNS Validation Too?

Yes—especially when the DNS zone is hosted in Amazon Route 53.

A simplified example is:

resource "aws_acm_certificate" "api_certificate" {

  domain_name       = "api.example.com"
  validation_method = "DNS"

  lifecycle {
    create_before_destroy = true
  }
}

data "aws_route53_zone" "example" {
  name = "example.com"
}

resource "aws_route53_record" "certificate_validation" {

  for_each = {
    for dvo in aws_acm_certificate.api_certificate.domain_validation_options :
    dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  zone_id = data.aws_route53_zone.example.zone_id

  name    = each.value.name
  type    = each.value.type
  records = [each.value.record]

  ttl = 60
}

resource "aws_acm_certificate_validation" "api_certificate" {

  certificate_arn = aws_acm_certificate.api_certificate.arn

  validation_record_fqdns = [
    for record in aws_route53_record.certificate_validation :
    record.fqdn
  ]
}

Now Terraform is orchestrating much more of the process:

Terraform
    │
    ├── Request ACM Certificate
    │
    ▼
ACM
    │
    ├── Generate DNS Validation Record
    │
    ▼
Terraform
    │
    ├── Create Route 53 Record
    │
    ▼
Route 53
    │
    ▼
ACM verifies domain control
    │
    ▼
Certificate Issued

This removes several manual steps from the traditional certificate-management process.

---

Q: Where Does the CSR Go in This Architecture?

This is an interesting architectural change.

In a traditional PKI workflow, the CSR is very visible:

Server
   │
   ├── Private Key
   │
   └── CSR
          │
          ▼
          CA

With a managed service such as ACM, those lower-level operations are largely abstracted away from the administrator.

From your perspective, the workflow becomes:

Terraform

   aws_acm_certificate
           │
           ▼
          ACM
           │
           ▼
    Domain Validation
           │
           ▼
     Certificate Issued

You request a certificate through an API rather than manually constructing and transporting a CSR.

---

Q: What About Client and Machine Certificates?

This is where private PKI becomes particularly important.

Suppose an AI agent needs to authenticate itself to an API Gateway:

AI Agent
    │
    │ Client Certificate
    ▼
API Gateway
    │
    │ Validate Certificate
    ▼
Authorized API

The organization might operate a private CA hierarchy:

Enterprise Root CA
        │
        ▼
Workload Intermediate CA
        │
        ▼
AI Agent Certificate

Tools such as AWS Private CA, HashiCorp Vault PKI, Microsoft AD CS, SPIFFE/SPIRE-based systems, and other enterprise PKI platforms can automate this process.

---

Q: Why Are Short-Lived Certificates Becoming Popular?

Traditional enterprise certificates might remain valid for months or even years.

Modern workload identity systems increasingly use short-lived certificates.

For example:

Workload Starts
      │
      ▼
Authenticate Workload
      │
      ▼
Request Certificate
      │
      ▼
Private CA
      │
      ▼
Certificate
Validity: Hours / Days
      │
      ▼
Workload

Before the certificate expires, the workload obtains another certificate automatically.

This can reduce reliance on long-lived credentials and reduce the useful lifetime of a compromised certificate/key pair.

---

Q: Does Automation Mean the CA Gets the Private Key?

Not necessarily.

This is an important distinction.

In a traditional CSR-based architecture:

Workload
   │
   ├── Private Key ───────────► Keep Secret
   │
   └── Public Key
           │
           ▼
          CSR
           │
           ▼
           CA

The CA signs a certificate containing the public key.

The private key does not need to be sent to the CA.

Managed certificate platforms can work differently. For example, ACM can generate and manage the private key associated with an ACM-issued certificate on your behalf.

So there are two broad models:

Traditional / Workload PKI

Private Key → controlled by workload
CSR         → sent to CA
Certificate → returned by CA

versus:

Managed Certificate Service

Certificate Request
        │
        ▼
Managed Platform
        │
        ├── Key Management
        ├── Validation
        ├── Certificate
        └── Renewal

Both automate certificate management, but the key-management architecture is different.

---

Q: What Is the Bigger Architectural Shift?

Certificate automation is really about moving from certificate administration to certificate lifecycle management.

The old model was:

Administrator
     │
     ├── Generate key
     ├── Generate CSR
     ├── Submit CSR
     ├── Download certificate
     ├── Install certificate
     ├── Track expiration
     └── Renew certificate

The modern model looks more like:

Application / Infrastructure
          │
          ▼
Certificate Automation Platform
          │
          ├── Authenticate requester
          ├── Validate policy
          ├── Issue certificate
          ├── Deploy certificate
          ├── Monitor expiration
          └── Renew / rotate

Tools such as Let’s Encrypt + ACME, AWS ACM, AWS Private CA, Vault PKI, cert-manager, and enterprise PKI platforms make certificates part of an automated infrastructure lifecycle rather than something administrators manually manage.

For cloud-native environments, the ideal end state is often simple:

Applications should not have to know that a certificate is about to expire.

The certificate-management system should request, validate, issue, deploy, renew, and rotate certificates automatically—with the private keys appropriately protected throughout their lifecycle.