(certificatemanager): DnsValidatedCertificate does not support creating cert for imported hosted zone by id only

[zxkane]

The validate() of DnsValidatedCertificate requires the concreted hostname from IHostedZone object. Can not create DnsValidatedCertificate only importing a hosted zone from its ID. The hostname is redundant, the hosted zone id is enough for importing existing hosted zone.

aws-cdk/packages/@aws-cdk/aws-certificatemanager/lib/dns-validated-certificate.ts

Lines 111 to 119 in 0757686

	protected validate(): string[] {
	const errors: string[] = [];
	// Ensure the zone name is a parent zone of the certificate domain name
	if (!cdk.Token.isUnresolved(this.normalizedZoneName) &&
	this.domainName !== this.normalizedZoneName &&
	!this.domainName.endsWith('.' + this.normalizedZoneName)) {
	errors.push(`DNS zone ${this.normalizedZoneName} is not authoritative for certificate domain name ${this.domainName}`);
	}
	return errors;

Reproduction Steps

Reproduce the validation error using below code snippet,

    const parentStack = new Stack(new App(), 'TestStack');
    const domainNamePara = new CfnParameter(parentStack, 'DashboardDomain', {
      type: 'String',
    });
    const r53HostZoneIdPara = new CfnParameter(parentStack, 'Route53HostedZoneId', {
      type: 'AWS::Route53::HostedZone::Id',
    });

new DnsValidatedCertificate(this, 'CustomDomainCertificateForCloudFront', {
          domainName: domainNamePara.valueAsString,
          hostedZone: HostedZone.fromHostedZoneId(this, 'ImportedHostedZone', r53HostZoneIdPara.valueAsString),
          region: 'us-east-1',
        });

What did you expect to happen?

What actually happened?

Environment

• CDK CLI Version : 1.91.0
• Framework Version:
• Node.js Version:
• OS :
• Language (Version):

Other

---

This is 🐛 Bug Report

[njlynch]

Hi @zxkane ,

The requirement to use a HostedZone with a name was an explicit decision to allow for the validation shown and prevent deploy-time failures where the hosted zone domain doesn't match the certificate's domain. This validation and restriction have been in place since the initial creation of this construct 2 years ago, and to my knowledge, this is the first time this has been suggested to be a bug. I'd like to understand better what impact this has.

Can you explain a bit more what the impact is for you? Is it just the annoyance of having to import by attributes (e.g., HostedZone.fromHostedZoneAttributes) instead of ID, or is there something else I'm missing?

[zxkane]

Hi Nick,

Below is my use case,

I’m building a solution by CDK, the goal is the customer can deploy the solution via CloudFormation with few inputs. The solution brings a web portal distributed by CloudFront, the customer can input their custom domain name and select existing public hosted zone of Route 53. It will give the customers out-of-the-box web portal after deploying the solution.

For above scenario, the ideal user experience is the customer just input the custom domain of web portal and select existing public hosted zone of Route53 for creating custom domain’s DNS record. If the solution also requires an additional input for the domain of the hosted zone of Route 53, it is redundant to the hosted zone id. All of those inputs are CloudFormation parameters in the CDK app, they are tokens not able to be verified by validate() method when synthesizing the application.

So my proposal is updating the validate() method to allow the value of normalizedZoneName is undefined.

[njlynch]

I agree we could make this validation -- while useful -- optional.

As a work-around, you could import the hosted zone by attributes, and just have the hosted zone name be the desired domain name. This isn't accurate, but given the limited usage here, would be enough to unblock you:

new DnsValidatedCertificate(this, 'CustomDomainCertificateForCloudFront', {
  domainName: domainNamePara.valueAsString,
  hostedZone: HostedZone.fromHostedZoneAttributes(this, 'ImportedHostedZone', {
    hostedZoneId: r53HostZoneIdPara.valueAsString,
    zoneName: domainNamePara.valueAsString,
  }),
  region: 'us-east-1',
});

[mattserrano]

This issue also prevents users from creating a DnsValidatedCertificate across account boundaries because HostedZone.fromHostedZoneAttributes() requires the hosted zone to reside in the environment account. There doesn't appear to be a way to create a "dummy" HostedZone that doesn't require calls to Route53 anymore (unless I've missed something).

[njlynch]

This issue also prevents users from creating a DnsValidatedCertificate across account boundaries because HostedZone.fromHostedZoneAttributes() requires the hosted zone to reside in the environment account.

To create a DnsValidatedCertificate across account boundaries, the Lambda function handler that actually makes the request to ACM would need to assume a role in another account (to make the route53 calls). This work is being tracked in #8934.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.