Terraform module to request an ACM certificate for a domain name and create a CNAME record in the DNS zone to complete certificate validation

Home Page: https://cloudposse.com/accelerate

License: Apache License 2.0

Makefile 10.65% HCL 66.74% Go 22.61%

terraform terraform-modules aws acm request-certificate tls ssl ssl-certificates hcl2

terraform-aws-acm-request-certificate's Issues

`aws_route53_record.default` errror

Error: module.acm_request_certificate.aws_route53_record.default: 1 error(s) occurred:

* module.acm_request_certificate.aws_route53_record.default: At column 3, line 1: lookup: argument 1 should be type map, got type string in:

${lookup("null_resource.default.${count.index}", "resource_record_type")}

Sorry i just copy pasting my error because i'm a beginner with terraform,

(i'm using the configuration on the readme (with my domain name)

what

Add example invocation

why

We need this so we can soon enable automated continuous integration testing of module

Certificate validation exception

Found a bug? Maybe our Slack Community can help.

Describe the Bug

A clear and concise description of what the bug is.

I have a certificate.tf in which I have a domain + subject_alternative_names. This worked well until the aws provider (hashicorp/aws) version was changed to 4.12.0

Expected Behavior

A clear and concise description of what you expected to happen.

Terraform doesn't error while planning or applying

Steps to Reproduce

Steps to reproduce the behavior:

Requesting a certificate where the aws provider is at version 4.12.0 will fail with an error. A snippet of my main.tf where the aws provider is used is shown below:

...
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "4.12.0"
    }
    http = {
      source  = "terraform-aws-modules/http"
      version = "2.4.1"
    }
  }
...

The error:

╷
│ Error: reading ACM Certificate (2022-04-01 04:14:15.359 +0000 UTC): ValidationException: 1 validation error detected: Value '2022-04-01 04:14:15.359 +0000 UTC' at 'certificateArn' failed to satisfy constraint: Member must satisfy regular expression pattern: arn:[\w+=/,.@-]+:acm:[\w+=/,.@-]*:[0-9]+:[\w+=,.@-]+(/[\w+=,.@-]+)*
│
│   with module.acm_request_certificate.aws_acm_certificate_validation.default[0],
│   on .terraform/modules/acm_request_certificate/main.tf line 49, in resource "aws_acm_certificate_validation" "default":
│   49: resource "aws_acm_certificate_validation" "default" {

If I change the version of the provider to be >= 4.11.0, terraform completes successfully.

Below is the TF configuration (domain and other data has been redacted):

provider "aws" {
  region  = var.region
  profile = var.profile
}


terraform {
  required_version = ">= 1.1.4"

  backend "s3" {
  # s3 specific parameters
  }

  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "4.12.0"
    }
    http = {
      source  = "terraform-aws-modules/http"
      version = "2.4.1"
    }
  }

}

module "acm_request_certificate" {
  source = "cloudposse/acm-request-certificate/aws"
  version                           = "v0.16.0"
  domain_name                       = aws_route53_zone.SOME_ZONE.name
  process_domain_validation_options = true
  ttl                               = "300"
  subject_alternative_names         = ["*.SOME_ZONE.com", "*.SUBDOMAIN.SOME_ZONE.com"]
  wait_for_certificate_issued       = true
}


resource "aws_route53_zone" "SOME_ZONE" {
  name = "SOME_ZONE.com"
}

Screenshots

If applicable, add screenshots or logs to help explain your problem.

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

OS: [e.g. Linux, OSX, WSL, etc]
Version [e.g. 10.15]

Additional Context

Add any other context about the problem here.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

terraform

versions.tf

hashicorp/terraform >= 0.13

aws >= 3.0

Check this box to trigger a request for Renovate to run again on this repository

Wrongly used local instead of variable

Hi,

In the latest release a local is wrongly used instead of a var:

terraform-aws-acm-request-certificate/main.tf

Line 14 in f6f10a5

name = "${local.zone_name}."

This breaks using this module with the error:

Error: Error asking for user input: 1 error(s) occurred:

* module.default_wildcard_cert.local.zone_name: local.zone_name: 1:25: unknown variable accessed: var.domain_name in:

${var.zone_name == "" ? var.domain_name : var.zone_name}

`wait_for_certificate_issued` input not waiting until the certificate is issued

Describe the Bug

First time applying my Terraform stack ends in:

Error: creating ELBv2 Listener (arn:aws:elasticloadbalancing:eu-central-1:128840427886:loadbalancer/app/XXX/9202ae7b846a2e1c): UnsupportedCertificate: The certificate 'arn:aws:acm:eu-central-1:128840427886:certificate/e7050367-4b27-4582-8157-3fa96710fccd' must have a fully-qualified domain name, a supported signature, and a supported key size.

after waiting some minutes the next apply show the change of the validation:

module.acm.module.acm_request_certificate.aws_acm_certificate.default[0] has changed
  ~ resource "aws_acm_certificate" "default" {
        id                        = "arn:aws:acm:eu-central-1:128840427886:certificate/e7050367-4b27-4582-8157-3fa96710fccd"
      ~ status                    = "PENDING_VALIDATION" -> "ISSUED"
      + tags                      = {}
        # (7 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

The next apply was sucessfully completed .

I have set wait_for_certificate_issued = true
it should not prevent this ?

Update to aws-provider version 3.0

Describe the Bug

See: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-3-upgrade#domain_validation_options-changed-from-list-to-set

Expected Behavior

Module should not error out when upgrading provider to 3.0.

Steps to Reproduce

Steps to reproduce the behavior:

Pin aws-provider to 3.0
Run 'terraform apply' on an existing module
See error similar to error documented on the upgrade notes

Add ability to specify key_algorithm for certs setup with this module

Describe the Feature

As described in this blog post (https://aws.amazon.com/blogs/security/how-to-evaluate-and-use-ecdsa-certificates-in-aws-certificate-manager/), it is now possible to issue ECDSA certs using ACM. And the underlying Terraform module (https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/acm_certificate) supports the key_algorithm option that lets us set that. However this module doesn't currently allow passing that value in

Expected Behavior

I'd expect to be able to pass key_algorithm=EC_prime256v1 and see the appropriate cert generated in ACM

Use Case

ECDSA certs use less bandwidth and computation power to work. They're starting to be used more heavily in IoT deploys as described in the above blog post

Describe Ideal Solution

We'd add a new option to this module

Alternatives Considered

No response

Additional Context

No response

Provide extra variable for the route53_zone data source

Problem

I want to create this certificate:

domain_name                  = "site.example.org"
subject_alternative_names = ["www.site.example.org"]

My existing Route53 hosted zone is example.org.

The module fails because it looks for the site.example.org zone, which does not exist. I want to keep my example.org zone and I don't want to create a wildcard certificate.

Solution

add extra variable zone_name
use variable zone_name as name for the route53_zone data source if it exists:

variable "zone_name" {
  type        = "string"
  default     = ""
  description = "The Hosted Zone name of the desired Hosted Zone"
}

data "aws_route53_zone" "default" {
  count        = "${var.process_domain_validation_options == "true" && var.validation_method == "DNS" ? 1 : 0}"
  name         = "${local.zone_name}"
  private_zone = false
}

locals {
  zone_name = "${var.zone_name == "" ? var.domain_name. : var.zone_name}"
}

I am happy to write a PR if you agree with the proposed solution.

external DNS validation (e.g. Cloudflare)

Have a question? Please checkout our Slack Community or visit our Slack Archive.

Describe the Feature

It would be great if the module could be used with external DNS validation (e.g. Cloudflare).
This is already implemented in [https://registry.terraform.io/modules/terraform-aws-modules/acm/aws/latest](similar module)

Choosing the right zone for each SAN when attaching validation records

Found a bug? Maybe our Slack Community can help.

Describe the Bug

When you have two SANs that belong to different zones, the module tries to add validation records to the incorrect zone.

Expected Behavior

It should add validation records to zones:

foo.baz.bar.com and bar.com

Steps to Reproduce

Steps to reproduce the behavior:
Say you have these two zones:

zone 1: bar.com
zone 2: foo.baz.bar.com

You want a cert that allows you to use both zones so you do this:

module "acm_request_certificate_east_coast" {
  source = "cloudposse/acm-request-certificate/aws"

  domain_name                       = "foo.baz.bar.com"
  process_domain_validation_options = true
  ttl                               = "300"
  subject_alternative_names         = ["*.foo.baz.bar.com", "*.bar.com"]

  providers = {
    aws = aws.use1
  }
}

When I terraform apply, the module does a data lookup for the zone:

baz.bar.com

The expectation is that the zones it should look up:

foo.baz.bar.com
bar.com

Screenshots

N/A

Environment (please complete the following information):

Mac OS

Additional Notes

In chatting on Slack I suggested this:

Instead of trying to guess what zone to put each SAN in, just have the user specify it manually:

module "cert_request" {
  subject_alternative_names = [
    {
      zone_to_lookup = "foo.baz.com",
      names          = ["a.foo.baz.com", "b.foo.baz.com"]
    },
   {
      zone_to_lookup = "*.baz.com",
      names          = ["bob.baz.com", "alice.baz.com"]
    }
  ]
  # etc etc

Module broken if only passing domain name

Describe the Bug

Just passing the domain_name to request the certificate will end in error:

aws_route53_zone.root: Creating...
aws_route53_zone.root: Still creating... [10s elapsed]
aws_route53_zone.root: Still creating... [20s elapsed]
aws_route53_zone.root: Still creating... [30s elapsed]
aws_route53_zone.root: Still creating... [40s elapsed]
aws_route53_zone.root: Creation complete after 44s [id=Z100510839VMYCIY3X0FZ]
module.acm.data.aws_route53_zone.default["io"]: Reading...
module.acm.data.aws_route53_zone.default["example.io"]: Reading...
module.acm.aws_acm_certificate.default[0]: Creating...
module.acm.data.aws_route53_zone.default["example.io"]: Read complete after 1s [id=Z100510839VMYCIY3X0FZ]
module.acm.aws_acm_certificate.default[0]: Creation complete after 6s [id=arn:aws:acm:us-west-2:976668483278:certificate/5a505039-cec1-4407-a629-a71fd18f227a]
╷
│ Error: no matching Route53Zone found
│
│   with module.acm.data.aws_route53_zone.default["io"],
│   on .terraform/modules/acm/main.tf line 38, in data "aws_route53_zone" "default":
│   38: data "aws_route53_zone" "default" {
│
╵

It seems to be trying to get the hosted zone for both "example.io" and just "io" even if I am just passing "example.io" as domain_name. Because the 2nd hosted zone doesn't exist, the module fails.

This works fine if we pick version 0.16.3 of the module.

Expected Behavior

ACM certificate gets created.

Steps to Reproduce

This small code snippet should do it:

resource "aws_route53_zone" "root" {

  name    = "example.io"
  comment = "DNS zone for the root domain"
}

module "acm" {

  source  = "cloudposse/acm-request-certificate/aws"
  version = "0.17.0"

  enabled = true

  domain_name                       = "example.io"
  process_domain_validation_options = true
  ttl                               = 300
  subject_alternative_names         = [format("*.%s", "example.io")]

  depends_on = [aws_route53_zone.root]
}

Screenshots

No response

Environment

linux_amd64
Module version: 0.0.17
Terraform version: Terraform v1.3.8

Additional Context

No response

Feature Request - Timeout for wait_for_certificate_issued

Describe the Feature

As of now if one set wait_for_certificate_issued to true, terraform waits forever. It would be good to have some timeout defined.

Describe Ideal Solution

Maybe we can have some timeouts defined in a variable like below and configure it.

wait_for_certificate_issued_timeout: "10m"

Alternatives Considered

None as of now, I had to hit Ctrl + C and re-run the terraform job with wait_for_certificate_issued as false.

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Does not work if Route53 Zone is not created yet and no depends_on strategy implemented - Error: no matching Route53Zone found

The module works fine after having route53 zone created.
Switching now to a new/fresh workspace, and I get the error

Error: no matching Route53Zone found

  on .terraform/modules/dns.public_acm_request_certificate/main.tf line 19, in data "aws_route53_zone" "default":
  19: data "aws_route53_zone" "default" {

This snippet of my TF plan :

resource "aws_route53_zone" "publiczone" {
  lifecycle {
    prevent_destroy = true
  }
  count     = length(var.public_zone_name) > 0 ? 1 : 0
  comment   = "Public Hosted Zone for ${terraform.workspace} environment"
  name      = var.public_zone_name
  tags      = {
    Environment = terraform.workspace
  }
}

module "public_acm_request_certificate" {
  source                                                         = "git::https://github.com/cloudposse/terraform-aws-acm-request-certificate.git?ref=0.4.0"
  domain_name                                           = var.public_zone_name
  process_domain_validation_options = true
  ttl                                                                  = "300"
  subject_alternative_names                   = ["*.${var.public_zone_name}"]
  tags = {
      ZoneId                                                   = join("", aws_route53_zone.publiczone.*.zone_id)
  }
}

As workaround, and as you can see in the snippet, I tried to link the module with the zone by assigning the zone_id attribute as value for tags (module variable).. But the same issue , the same error.

Error using lookup

Hi there, A lookup is failing for me. See below. Thanks, Phil.

module "acm_request_certificate" {
  source                            = "git::https://github.com/cloudposse/terraform-aws-acm-request-certificate.git?ref=0.2.0"
  domain_name                       = "example.com"
  process_domain_validation_options = "true"
  ttl                               = "60"
  subject_alternative_names         = ["*.example.com", "*.foo.example.com"]
}

$ terraform version
Terraform v0.11.8
+ provider.aws v1.35.0
+ provider.local v1.1.0
+ provider.null v1.0.0
+ provider.random v2.0.0

$ terraform apply
...
* module.acm_request_certificate.aws_route53_record.default: At column 3, line 1: lookup: argument 1 should be type map, got type string in:

${lookup("null_resource.default.${count.index}","resource_record_name")}

Issue when creating certificate with wildcards

Found a bug? Maybe our Slack Community can help.

Describe the Bug

The below causes an invalid index error (see screenshots section for output)

module "acm_internal" {
  source  = "cloudposse/acm-request-certificate/aws"
  version = "0.8.0"

  domain_name                       = "*.internal.example_com"
  zone_name                         = aws_route53_zone.example_com.name
  subject_alternative_names = [
    "*.example_com"
  ]

  process_domain_validation_options = true
  ttl                               = "60"

  tags = module.tagging.tags
}

Expected Behavior

Having wildcards in the domain_name and subject_alternative_names is valid; it should not cause the issue above.

Steps to Reproduce

Plan and apply the given example.

Screenshots


  on .terraform/modules/acm_internal/main.tf line 30, in resource "aws_route53_record" "default":
  30:   name            = lookup(local.domain_validation_options_list[count.index], "resource_record_name")
    |----------------
    | count.index is 0
    | local.domain_validation_options_list is set of object with 2 elements

This value does not have any indices.


Error: Invalid index

  on .terraform/modules/acm_internal/main.tf line 30, in resource "aws_route53_record" "default":
  30:   name            = lookup(local.domain_validation_options_list[count.index], "resource_record_name")
    |----------------
    | count.index is 1
    | local.domain_validation_options_list is set of object with 2 elements

This value does not have any indices.


Error: Invalid index

  on .terraform/modules/acm_internal/main.tf line 31, in resource "aws_route53_record" "default":
  31:   type            = lookup(local.domain_validation_options_list[count.index], "resource_record_type")
    |----------------
    | count.index is 0
    | local.domain_validation_options_list is set of object with 2 elements

This value does not have any indices.


Error: Invalid index

  on .terraform/modules/acm_internal/main.tf line 31, in resource "aws_route53_record" "default":
  31:   type            = lookup(local.domain_validation_options_list[count.index], "resource_record_type")
    |----------------
    | count.index is 1
    | local.domain_validation_options_list is set of object with 2 elements

This value does not have any indices.


Error: Invalid index

  on .terraform/modules/acm_internal/main.tf line 32, in resource "aws_route53_record" "default":
  32:   records         = [lookup(local.domain_validation_options_list[count.index], "resource_record_value")]
    |----------------
    | count.index is 0
    | local.domain_validation_options_list is set of object with 2 elements

This value does not have any indices.


Error: Invalid index

  on .terraform/modules/acm_internal/main.tf line 32, in resource "aws_route53_record" "default":
  32:   records         = [lookup(local.domain_validation_options_list[count.index], "resource_record_value")]
    |----------------
    | count.index is 1
    | local.domain_validation_options_list is set of object with 2 elements

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

OS: Linux
Version 0.13.4
Terraform AWS provider 3.11.0

Additional Context

Add any other context about the problem here.

Error: value of 'count' cannot be computed

Even after fixing #16 (dup of #8), release 0.3.0 of this module does not work with Terraform v0.11.13

* module.certificate.null_resource.default: null_resource.default: value of 'count' cannot be computed

This is due to an attempt to allow the module to be disabled, which is probably not possible in Terraform v0.11.

Workaround: reverting to release 0.1.1

Support SANs with multiple hosted zones

Found a feature? Maybe our Slack Community can help.

Describe the Feature

process_domain_validation_options breaks if subject_alternative_names contains different zones

I am using distinct domains in my subject_alternative_names variable...

  domain_name                       = "website.foundation"
  process_domain_validation_options = true
  subject_alternative_names         = [
    "*.website.foundation",
    "websitefoundation.org",
    "*.websitefoundation.org",
  ]

Expected Behavior

It would be nice to process domain validation options across multiple hosted zones.

Warnings on provider version

What is the provider null used for? I didn't find related usage in the code.

$ terraform init                                                                                                                    Initializing modules...
- module.acm_request_certificate
  Getting source "git::https://github.com/cloudposse/terraform-aws-acm-request-certificate.git?ref=0.2.2"

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "null" (1.0.0)...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.null: version = "~> 1.0"

cloudposse / terraform-aws-acm-request-certificate Goto Github PK

terraform-aws-acm-request-certificate's Issues

what

why

Describe the Bug

Expected Behavior

Steps to Reproduce

Screenshots

Environment (please complete the following information):

Additional Context

Detected dependencies

Describe the Bug

Describe the Bug

Expected Behavior

Steps to Reproduce

Describe the Feature

Expected Behavior

Use Case

Describe Ideal Solution

Alternatives Considered

Additional Context

Problem

Solution

Describe the Feature

Describe the Bug

Expected Behavior

Steps to Reproduce

Screenshots

Environment (please complete the following information):

Additional Notes

Describe the Bug

Expected Behavior

Steps to Reproduce

Screenshots

Environment

Additional Context

Describe the Feature

Describe Ideal Solution

Alternatives Considered

Describe the Bug

Expected Behavior

Steps to Reproduce

Screenshots

Environment (please complete the following information):

Additional Context

Describe the Feature

Expected Behavior

Recommend Projects

Recommend Topics

Recommend Org