Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create route53 records for SAN domains #1

Closed
trnubo opened this issue Feb 14, 2019 · 7 comments
Closed

Create route53 records for SAN domains #1

trnubo opened this issue Feb 14, 2019 · 7 comments

Comments

@trnubo
Copy link

trnubo commented Feb 14, 2019

When creating the following

module "acm_example_com" {
  # For use with CloudFront the ACM certificate must be created in us-east-1
  providers {
    aws = "aws.us-east-1"
  }

  source  = "terraform-aws-modules/acm/aws"
  version = "1.1.0"

  domain_name  = "example.com"
  zone_id      = "${aws_route53_zone.example.zone_id}"

  subject_alternative_names = [
    "www.example.com",
  ]

  tags = {
    Name = "example.com"
  }
}

I get the following error

* module.acm_example.aws_acm_certificate_validation.this: 1 error(s) occurred:

* aws_acm_certificate_validation.this: 1 error occurred:
	* missing www.example.com DNS validation record: _6xxxb.www.example.com

The module doesn't create the route53 records for each of the SAN domains.

Is this intended and I'm using the module wrong or is this a limitation of the module?

Thanks,

@antonbabenko
Copy link
Member

I've just released v1.2.0 where multiple route53 records are created. This should fix the problem you are facing, but I could not properly test it.

This module is almost identical now to this blog post - https://manicminer.io/posts/terraform-aws-acm-certificates-for-multiple-domains/ by @manicminer

@manicminer
Copy link

@antonbabenko Incidentally, I just added support for multiple zones to my module in case you're interested (it is somewhat hacky in true Terraform fashion)

manicminer/terraform-aws-acm-certificate@cb368856fc

@antonbabenko
Copy link
Member

Looks nice. Thanks for sharing!

@tareks
Copy link

tareks commented Mar 4, 2019

@antonbabenko Note sure if this was an unintended side effort of the 1.2.0 fix mentioned above, but it looks like there is regression for a certificate request with an identical route53 entry, such as:

  domain_name = "test.domain.com"

  subject_alternative_names = [
   "*.test.domain.com"
  ]

The error generated in 1.2.0 as it attempts to insert the same validation CNAME record twice is:

* aws_route53_record.validation.0: [ERR]: Error building changeset: InvalidChangeBatch: [Tried to create resource record set [name='<redacted>', type='CNAME'] but it already exists]

Reverting back to 1.1.0 fixed this for me.

Is this intended behavior? I must admit that I'm not sure if it makes sense or not to generate the cert for that zone. It could probably be sufficient for the wildcard in my case, but not sure about others..

@antonbabenko
Copy link
Member

@tareks Yes, the problem you are having is related to the change introduced lately, you can try to specify validate_certificate = false as a workaround or you can take a look into https://github.com/manicminer/terraform-aws-acm-certificate

@reegnz
Copy link

reegnz commented Apr 10, 2019

The example in the README also produces this error. :( I just spent at least an hour debugging and trying to filter out duplicate CNAME records but that is close to impossible with Terraform 0.11 :(
I guess this could be fixed on the provider side.

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants