aws_acm_certificate_validation wrongly reporting invalid certificate_arn on v4.12.0

[lauren-themis]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

1.1.8, and the just-released v4.12.0

Affected Resource(s)

aws_acm_certificate_validation

Terraform Configuration Files

resource "aws_route53_zone" "test" {
  name = "some-zone."
}

resource "aws_acm_certificate" "test" {
  domain_name       = "*.some-zone"
  validation_method = "DNS"
}

resource "aws_route53_record" "test-a-record" {
  zone_id = aws_route53_zone.test.zone_id
  name    = aws_route53_zone.test.name
  type    = "A"
  alias {
    name                   = some_target_hostname
    zone_id                = lb_zone
    evaluate_target_health = true
  }
  
  lifecycle {
    ignore_changes = [records, ttl]
  }
}

resource "aws_route53_record" "test" {
  for_each = {
    for dvo in aws_acm_certificate.test.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = aws_route53_zone.test.zone_id
}

resource "aws_acm_certificate_validation" "test" {
  certificate_arn         = aws_acm_certificate.test.arn
  validation_record_fqdns = [for record in aws_route53_record.test : record.fqdn]
}

Expected Behavior

Terraform plan should have found no changes on my aws_acm_certificate_validation resource in this case.

Actual Behavior

Error: reading ACM Certificate (2022-04-25 20:00:08.983 +0000 UTC): 
ValidationException: 1 validation error detected: Value '2022-04-25 20:00:08.983 +0000 UTC' at 'certificateArn' failed to satisfy constraint: 
Member must satisfy regular expression pattern: arn:[\w+=/,.@-]+:acm:[\w+=/,.@-]*:[0-9]+:[\w+=,.@-]+(/[\w+=,.@-]+)*

(it errors out reading the aws_acm_certificate_validation's certificate_arn)

 

Steps to Reproduce

terraform plan with an existing, unchanged aws_acm_certificate_validation in state, after upgrading to v4.12.0

This did NOT occur on any previous releases (I hadn't version locked my providers yet for this new setup, and it just started.)

Locking my version to v4.11.0 resolved the issue, plan worked as expected.

[ahilmathew]

Can confirm that I am also facing the same issue on v4.12.0

╷
│ Error: reading ACM Certificate (2022-03-15 01:00:45.675 +0000 UTC): ValidationException: 1 validation error detected: Value '2022-03-15 01:00:45.675 +0000 UTC' at 'certificateArn' failed to satisfy constraint: Member must satisfy regular expression pattern: arn:[\w+=/,.@-]+:acm:[\w+=/,.@-]*:[0-9]+:[\w+=,.@-]+(/[\w+=,.@-]+)*
│ 
│   with module.spoke_network.module.acm.aws_acm_certificate_validation.default[0],
│   on ../modules/acm/main.tf line 30, in resource "aws_acm_certificate_validation" "default":
│   30: resource "aws_acm_certificate_validation" "default" {
│ 
╵
Releasing state lock. This may take a few moments..

I wasn't locking the provider version earlier, but now have locked to v4.11.0 and that has fixed the issue.

[jufemaiz]

+1 this.

Will lock to v4.11.0.

Seems like a pretty bad break?

[MatthewFagan]

Same issue here. The certificatearn output is giving the certificate issue date instead of the arn. It breaks everything

[MatthewFagan]

The value in the tfstate file (as obtained through terraform state show) contains the correct arn

[jufemaiz]

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/acm_certificate_validation

v4.11.0...v4.12.0#diff-da27748319004d756e8526be1691fbfad4b2e7a5c2ffccf691e6447ea945a42dR98-R107

This is the problem.

[nodomain]

Same here - eagerly wanted to try out Serverless RDS Aurora v2 and hit the wall.
Waiting for the fix :)

[manfro3]

Same issue... waiting for a faster-than-light fix ;)

[neugeeug]

The same here ;)

[mediapills]

+1

[muhanics]

Deleted

[saurabhkdm]

+1

[mateuszkrasucki]

+1

[queeno]

+1

[schrill]

I can see that the pull request has been approved for fixing this but changes are yet to reflect compiled provider with tag v4.12.0

[FernandoMiguel]

I can see that the pull request has been approved for fixing this but changes are yet to reflect compiled provider with tag v4.12.0

4.12.0 introduced the issue
I would never expect for the fix to be released to the same tag

[edwardofclt]

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/acm_certificate_validation

v4.11.0...v4.12.0diff-da27748319004d756e8526be1691fbfad4b2e7a5c2ffccf691e6447ea945a42dR98-R107

This is the problem.

I almost wonder if in the next major release should change the id attribute name to last_issued. 🤔 Feels like the naming convention attributed to the confusion.

[schrill]

I can see that the pull request has been approved for fixing this but changes are yet to reflect compiled provider with tag v4.12.0

4.12.0 introduced the issue I would never expect for the fix to be released to the same tag

Don't know the versioning and deployment of artifacts schema here, build was x5 so I presumed for a bug they vould do x6 or what ever.

github-actions bot added this to the v4.13.0 milestone 6 minutes ago

Of course logical, build artifact had x5 suffix, not knowing the versioning schema typo'ed 4.12.0.

[svanharmelen]

Is v4.13.0 going to be released as a hotfix for this? Or are you going to hold off on the release for now and add more changes to it? As we are also pretty stuck on this one for the moment...

[jeffwnelson]

For the time being, just add the following to your terraform provider block.

terraform {
  required_version = ">= 1.1.9"

  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "= 4.11.0"
    }
  }
}

That will pin the aws provider to the previous version.

[svanharmelen]

I know, but we have like a "gazillion" repos so that would be quite some work to be honest... So if this release is going to take at least another day or so we'll do the work, but otherwise I prefer to wait for it.

[FernandoMiguel]

I know, but we have like a "gazillion" repos so that would be quite some work to be honest... So if this release is going to take at least another day or so we'll do the work, but otherwise I prefer to wait for it.

if it is that much work to handle an issue, you should always pin and use something like dependabot to bump versions.
you can not have both latest and not be ready to pin in case of breakage.

[svanharmelen]

No, we're perfectly fine with it and prefer to use latest. But it would be a shame if I spend the time to pin everything and then 5 minutes later v4.13.0 is released and I can revert the pinning again...

Hence my question about the expected release frame, just so I can make an educated guess if it worth the efforts.

[ewbankkit]

We are planning on releasing a v4.12.1 patch with this (and maybe one other) bug fix later today.

[github-actions]

This functionality has been released in v4.12.1 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[nodomain]

Thanks for the great news 😎

[lauren-themis]

Fix confirmed! Just tried the same resources on 4.12.1, everything worked ✅

Thanks for the quick fix y'all!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.