To give a specific case (though I’m seeking a general answer), say I’m using DNS validation to validate a x509 cert generate via AWS’s ACM service: resource "aws_acm_certificate" "example" { domain_name = "sub.example.com" subject_alternative_names = ["sub.region.example.com"] validation_meth…

I suspect you are correct with regards to AWS/ACM’s expectations. The issue is how to make that cleanly and reliably work with Terraform’s expectations? TF already deals with the “is ACM done issuing the cert” issue via a aws_acm_certificate_validation sudo resources. And transient resources would …

I don’t see an issue with Terraform or ACM here. The DNS validation entry can only overlap in a specific situation which is a wildcard certificate. Look at the table at the bottom of Option 1: DNS Validation - AWS Certificate Manager

The only case where different domains names overlap is that case. But I’m thinking of the case where different certs include the same domain name. (For example say that each region has an ALB addressed by a per-region record and latency-based-routing CNAME records are used to direct traffic to the c…

While multiple certificates with overlapping validation CNAMEs is an issue, to some extent this can be limited by the careful selection of the primary name and SANs. This is however a different issue to the one you were initially discussing - the DNS records should continue to exist after the initi…

Ah ok, I think got it now. I think there is a solution but not with ACM and managed renewals. When using ACM and managed renewals, you get a cert signed by AWS trusted root and it’s easy to deploy it to integrated service ( Services Integrated with AWS Certificate Manager - AWS Certificate Manager )…

@stuart-c : As far as I know, ACM validation doesn’t distinguish between the primary and alternate names; it requires validation of all of them independent. Swapping those around won’t make any difference. For the sake of argument, lets assume you are correct however about leaving the resource up: w…

@ohmer actually the reason for the different certs is the expectation that the cert should exactly match the list of domains that could resolve to that server/ALB/endpoint/etc. Even with externally generated certs that can be installed in multiple regions, I’d still go with the same setup. Also, t…

How would you know how long a resource is needed?

Which resource? The certs them self? That’s presumed to be “otherwise already known”. The CNAME records? That’s the $1k question. It should be “as long as any cert, in any config, needs it”. But that’s a really hard problem to resolve when you don’t have any way of telling what other configs exist.…

@bcsgh The problem is not Terraform here but ACM limitation/design/feature. You can try harder to bend Terraform but I don’t think your proposals are valid.

Proper way to deal with transient resources?

Terraform

Topic		Replies	Views
Unnecessary destruction when attributes depend on another resource that is destroyed Terraform	2	2297	July 8, 2020
Managing "transient" objects with Terraform Terraform	5	1420	March 4, 2022
Aws_acm_certificate.app_cert.domain_validation_options is a set of object, known only after apply AWS tf-aws-provider-release	1	2478	August 1, 2022
Local variable isn't correctly evaluated before resource creation Terraform	2	1177	October 10, 2019
Version 3.0, aws_route53_record and aws_acm_certificate validation AWS	1	1988	August 4, 2020

Proper way to deal with transient resources?

Related topics