AWS CDK - Generate and Validate Cert in us-east-1

[damogallagher]

Hi

When using the aws-cdk - I noticed that DnsValidatedCertificate was not deprecate. It mentions to use Certificate instead.

With DnsValidatedCertificate, I could specify the AWS region which is important.
I am deploying my infrastructure in eu-west-1.
When I want to associate the cert with a CloudFront Distribution, the cert must be in useast-1 as per the documentation.

I was wondering is it possible to specify that the cert is created in us-east-1 even though my other infrastructure is being created in eu-west-1?

Thanks
Damien

[fynnfluegge]

Hi @damogallagher,

I also facing this when I deploy to eu regions. There will be no issues if your infrastructure is hosted in eu-west-1 and the region of NewDnsValidatedCertificate is specified as us-east-1. I guess this is out of @aws-cdk scope, since the CA of the issued certs by AWS belongs to us-east-1 and cloudfront only validates the certificates to us-east-1 region.

Best,
Fynn

[damogallagher]

Hi @fynnfluegge

Thanks for getting back to me.
My infrastructure is in eu-west-1 so its important that I try and create the cert in the us-east-1 region for the region you specified with CloudFront.
By not being able to specify the certificate region in the Certificate construct, it means that I cannot move away from the Deprecated DnsValidatedCertificate.
I would feel this issue does lie with the CDK team unless there is another way to specify a certs region?

Thank you
Damien

[fynnfluegge]

I am not sure, but I think you cannot specify the region in certificate constructs because the CA belongs to us-east-1 anyways. So, it does not matter. But I always created my hosted zones out of the cdk infrastructure code and do a lookup, because it rarely changes and the whole infrastructure is hosted in eu-central-1. Maybe that helps:

// hosted zone & certificate
zone := awsroute53.HostedZone_FromLookup(stack, jsii.String("MyHostedZone"), &awsroute53.HostedZoneProviderProps{
	DomainName: "mydomain",
})

certificateArn := awscertificatemanager.NewDnsValidatedCertificate(stack, jsii.String("MySiteCertificate"), &awscertificatemanager.DnsValidatedCertificateProps{
	DomainName: "*.mydomain",
	HostedZone: zone,
	Region:     "us-east-1", // Cloudfront only checks this region for certificates.
})


// distribution & deployment
appViewerCertificate := awscloudfront.ViewerCertificate_FromAcmCertificate(
	certificateArn,
	&awscloudfront.ViewerCertificateOptions{
		SslMethod:      awscloudfront.SSLMethod_SNI,
		SecurityPolicy: awscloudfront.SecurityPolicyProtocol_TLS_V1_1_2016,
		Aliases:        "mydomain",
	},
)

[fynnfluegge]

found the related PR to this issue #21982, maybe the comments in PR will help

[damogallagher]

Thank you @fynnfluegge this issue link will be useful.

[therightstuff]

My takeaway from the discussion in #21982 is that the answer to @damogallagher's original question is "no". We now need to create a separate us-east-1 stack containing the certificate before we use the certificate in another region.

[stoyan-scava]

I created a pull request to undo the deprecation of DnsValidatedCertificate

#24543

[dendle]

Please provide us with a way of creating a certificate in us-east-1 from a stack that is not in us-east-1. The custom resource functionality in DnsValidatedCertificate provides this using custom resources - something that is very convenient. Please do not take this away without giving us an equally useable alternative.

[clouderops]

this really feels like a step backwards

    const certificate = new acm.DnsValidatedCertificate(this, 'mySiteCert', {
      domainName: domainName,
      hostedZone: zone,
      subjectAlternativeNames: [subDomainName],
      region: 'us-east-1'
    });

is just so much more convenient, compared to creating a extra stack, just to work around the region issue, when having to deal with cloudfront, and infra deployed in EU regions.

[peterwoodworth]

We have a feature request open for a new construct which will handle the creation of the Certificate from any region (by abstracting away the requirement to create a stack in us-east-1), and we'd be willing to review a PR that implements this.

You can still use DnsValidatedCertificate - deprecation here just means that we won't continue developing on it anymore because it's not the direction we want to continue to head in. However, you should still be able to use it for a long time to come, as we don't have any official plans for a v3.

I'd appreciate it if we could keep discussion around this in the feature request I've linked. It will help consolidate discussion, and also more people will be able to see that feature request and give it a thumbs up, which we use to help us decide what to work on

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.

[quantfreedom]

be sure to upvote this or thumbs up it or mark it as an answer so others know it works ... only if it works for you of course ... this way we can save others weeks of trying to figure this out

I have figured out a solution and i posted it here in this issue #9274 (comment)