The modern security perimeter relies almost entirely on the robust implementation of SSL/TLS certificates. As organizations scale their infrastructure across multi-cloud environments, hybrid Kubernetes clusters, and global Content Delivery Networks (CDNs), the manual management of certificates—including tracking expiration dates and rotating private keys—becomes a liability. Terraform provides the critical abstraction layer necessary to treat certificates as code, allowing platform engineers to automate the entire lifecycle from request and validation to deployment and renewal.

Effective certificate management via Terraform involves different strategies depending on whether the objective is public-facing security, internal microservices communication, or edge-cache encryption. By leveraging specific providers for Amazon Web Services (AWS), Google Cloud Platform (GCP), Kubernetes, and specialized CDN providers like Qwilt, teams can eliminate human error and ensure continuous encryption across the entire data path.

AWS Certificate Manager (ACM) Integration

AWS Certificate Manager (ACM) serves as the primary vehicle for securing public-facing applications within the AWS ecosystem. When integrated with Terraform, ACM allows for the seamless provisioning of SSL/TLS certificates that can be automatically associated with Application Load Balancers (ALB) and Amazon CloudFront distributions.

Architecture and Traffic Flow

A production-ready architecture for AWS certificate management typically follows a tiered approach to separate public traffic from internal service communication:

• Public Infrastructure: End users access applications through CloudFront and ALB, which utilize public certificates issued by ACM. This ensures that traffic is encrypted from the browser to the AWS edge.
• Internal Infrastructure: Internal services, such as those running on Amazon ECS, EKS, or Elastic Beanstalk, communicate via internal ALBs. These utilize private certificates issued by a Private CA to maintain a zero-trust security posture within the VPC.
• Validation Mechanism: Route 53 is typically utilized for DNS validation, allowing Terraform to prove domain ownership automatically without manual intervention.

Implementation Details

To manage ACM certificates, Terraform uses the aws_acm_certificate resource. A critical configuration detail is the validation_method, which should be set to DNS for automated environments.

The following configuration illustrates the deployment of a public certificate with Certificate Transparency logging enabled:

```hcl

Public Certificate Configuration

resource "awsacmcertificate" "main" {
domainname = var.domainname
validationmethod = "DNS"
subjectalternativenames = var.subjectalternative_names

options {
certificatetransparencylogging_preference = "ENABLED"
}

lifecycle {
createbeforedestroy = true
}

tags = merge(
var.tags,
{
Name = var.domain_name
}
)
}
```

The create_before_destroy lifecycle hook is essential here. Because SSL certificates are often attached to active load balancers, attempting to destroy a certificate before its replacement is created would lead to downtime. This setting ensures the new certificate is provisioned before the old one is removed.

Certificate Management in Kubernetes with Cert-Manager

While cloud-native managers like ACM work well for load balancers, Kubernetes environments require a more granular approach for managing certificates within the cluster, particularly for Ingress resources. The cert-manager module for Terraform automates the deployment of the cert-manager operator and the configuration of ClusterIssuers.

Deploying the Cert-Manager Module

The deployment requires a combination of providers including kubernetes, helm, and kubectl. The kubectl provider (specifically alekc/kubectl) is necessary for applying the custom resource definitions (CRDs) that cert-manager requires.

Minimal configuration for the cert-manager module:

hcl module "cert_manager" { source = "terraform-iaac/cert-manager/kubernetes" cluster_issuer_email = "[email protected]" }

HTTP ClusterIssuer and Automatic Validation

The module provides a flexible interface for automatic certificate validation via an HTTP ClusterIssuer. By default, the module utilizes a built-in HTTP solver. For this to function, the ingress class must match the deployed controller. The default configuration targets the "nginx" ingress class:

hcl solvers = [{ http01 = { ingress = { ingressClassName = "nginx" } } }]

To enable automatic TLS generation for a specific Ingress resource, developers must add the following annotation:
cert-manager.io/cluster-issuer = module.cert_manager.cluster_issuer_name

Handling Provider Deprecations

Users of the terraform-kubernetes-cert-manager module must be aware of changes in the Kubernetes provider. Starting from Kubernetes provider v3, the kubernetes_namespace resource is deprecated. The module has introduced kubernetes_namespace_v1 to address this.

Existing users are not migrated automatically. To handle this transition, users have two options:

1. Maintain the legacy state by setting use_namespace_v1 = false.
2. Perform a manual migration using state commands:
   • terraform state rm 'module.cert_manager.kubernetes_namespace.cert_manager[0]'
   • terraform import 'module.cert_manager.kubernetes_namespace_v1.cert_manager[0]' cert-manager

Google Cloud Certificate Authority Service (CAS)

For organizations requiring full control over their own Root and Subordinate CAs, Google Cloud's Certificate Authority Service (CAS) provides a highly available, cloud-hosted CA. Unlike ACM, which is primarily a managed service for certificates, CAS allows for the creation of a full CA hierarchy.

Hierarchy and Workflow

The Terraform workflow for GCP CAS is designed to support a structured trust chain:

• Root CA: Created within a CA pool. This is the anchor of trust.
• Subordinate CA: Created within the same or a different pool and signed by the Root CA. This CA is typically used for the actual issuance of end-entity certificates to avoid exposing the Root CA.
• CSR Generation: Terraform is used to generate the Certificate Signing Request (CSR), which is then submitted to the subordinate CA in the pool.

Access Control and Permissions

Before executing Terraform plans for GCP CAS, the executing identity must possess specific IAM permissions. Specifically, the roles/privateca.admin (CA Service Admin) role is mandatory. Without this role, the API calls to create pools or issue certificates will fail with permission denied errors.

Edge Certificate Management with Qwilt CDN

Content Delivery Networks (CDNs) require certificates to be available at the edge to terminate SSL/TLS connections close to the user. Qwilt CDN offers two distinct workflows for managing these certificates via Terraform, catering to both those who want full control over their private keys and those who prefer a managed lifecycle.

Upload Workflow (Manual Key Management)

In this workflow, the administrator provides the certificate, the full chain, and the private key. These are uploaded directly to the CDN.

• Integration: Once uploaded, the certificate is available to be linked to a site.
• Terraform Import: Existing certificates that were uploaded via a UI or API can be brought under Terraform management using the import command, which creates a named resource.
• Deployment: New certificates created via Terraform are automatically uploaded and available for management.

Certificate Template Workflow (CSR-based)

The Certificate Template feature is designed for higher security, as it eliminates the need to share private keys. The private key remains secure on the generating system.

• Managed CSR: Qwilt can manage the CSR lifecycle using Let's Encrypt.
• Self-Managed CSR: Users can generate and download a CSR to be signed by an external Certificate Authority of their choice.
• Terraform Support: The Qwilt Terraform Provider specifically supports the setup of the Qwilt-managed CSR workflow.

Activation and Linking

A signed certificate issued via a template does not automatically protect a site. There is a processing window of 30 to 60 minutes for the CA to issue the certificate and for it to become available. Status can be tracked via the signingState value returned by the Get or List CSR endpoints of the Certificate Manager API.

To activate the certificate, the template must be linked to a site activation resource:

hcl resource "qwilt_cdn_site_activation" "example" { site_id = qwilt_cdn_site_configuration.example.site_id revision_id = qwilt_cdn_site_configuration.example.revision_id certificate_template_id = qwilt_cdn_certificate_template.example.certificate_template_id }

Once the linking and publishing steps are completed once, Qwilt automatically handles subsequent renewals for the template-generated certificates.

Comparative Analysis of Certificate Management Workflows

The following table compares the operational characteristics of the various Terraform-managed certificate workflows discussed.

Technical Prerequisites and Project Structure

For a successful deployment of certificate management via Terraform, a standardized project structure is recommended to ensure modularity and reusability.

Required Tooling

• Terraform: Version 1.0.0 or later.
• AWS CLI: Configured with appropriate IAM permissions for ACM and Route 53.
• Kubernetes Provider: v3+ (utilizing kubernetes_namespace_v1).
• Helm/Kubectl: Installed for cert-manager deployment.

Recommended Directory Layout

Organizing certificates into modules allows for different configurations for production, staging, and development environments.

text terraform-cert-mgmt/ ├── main.tf # Root configuration and provider blocks ├── variables.tf # Global variables ├── outputs.tf # Certificate ARNs/IDs for external use ├── modules/ │ └── acm/ # AWS ACM specific logic │ ├── main.tf │ ├── variables.tf │ └── outputs.tf │ └── cert-manager/ # Kubernetes logic │ ├── main.tf │ └── variables.tf └── config/ └── domains.json # List of domains for bulk processing

Conclusion

Managing certificates through Terraform transforms a traditionally error-prone manual process into a reliable, version-controlled pipeline. By utilizing AWS ACM for public cloud entry points, Google Cloud CAS for internal private trust hierarchies, and cert-manager for Kubernetes-native workloads, organizations can ensure a comprehensive security posture. The integration of Qwilt CDN further extends this capability to the edge, providing options for both high-control key uploads and low-friction managed CSR workflows.

The primary technical challenge remains the coordination of validation and the handling of resource lifecycles. The use of create_before_destroy in AWS and the careful migration of namespace resources in Kubernetes are essential steps to prevent service interruption. As the industry moves toward shorter certificate lifespans to enhance security, the automation provided by these Terraform providers is no longer optional—it is a foundational requirement for scalable, secure infrastructure.

Sources

1. Managing AWS Certificate Manager (ACM) with Terraform
2. Certificate Management
3. terraform-kubernetes-cert-manager
4. using-terraform