certificatemanager: DnsValidatedCertificate tags with cross-stack usage fails on upgrade to 1.100

i am using certificatemanager.DnsValidatedCertificate(python version) to create and validate the certificate , this was working fine until cdk version(1.100.0) with 1.100.0 DnsValidatedCertificate is adding Tags to the custom resource as shown below .

because of these tags it is trying to update the custom resource and fails with the error as shown below .

i have tried to remove these tags explicitly by using the remove tags method but it could not remove them. cdk_core.Tags.of(core).remove( “ApplicationName”, include_resource_types=[“AWS::CloudFormation::CustomResource”] )

Reproduction Steps

self.hosted_zone_wildcard_certificate_us_east_1 = certificatemanager.DnsValidatedCertificate( self, “DnsValidationUsEast1”, hosted_zone=self.hosted_zone, # type: ignore domain_name=“*.” + self.hosted_zone_name, region=“us-east-1”, ) if self.hosted_zone_wildcard_certificate_us_east_1 is used in another stack then it will fail.

What did you expect to happen?

this should not update the custom custom .

What actually happened?

it was not suppose to update the custom resource by adding the Tags to the custom resource.

Environment

• **CDK CLI Version :1.100.0
• **Framework Version:1.100.0
• **Node.js Version:14.15.4
• MAC:big sur 11.3OS 😗*
• **Language (Version):python3.8.8

Other

---

This is 🐛 Bug Report

[Ranjith072]

Hi @njlynch , Any update on this ?

[njlynch]

(Tagging @timothy-farestad just for awareness.)

Reproduced with a minimal example (deploy both stacks with cdk 1.99.0; upgrade to 1.100.0; deploy Stack A (or both)):

import * as cdk from '@aws-cdk/core';
import * as r53 from '@aws-cdk/aws-route53';
import * as acm from '@aws-cdk/aws-certificatemanager';

export class StackA extends cdk.Stack {
  public readonly cert: acm.ICertificate;
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    this.cert = new acm.DnsValidatedCertificate(this, 'Cert', {
      domainName: 'issue14519.example.com',
      hostedZone: r53.HostedZone.fromHostedZoneAttributes(this, 'Zone', {
        hostedZoneId: 'Z2UMGPBOS12345',
        zoneName: 'example.com',
      }),
      region: 'eu-west-2',
    });
  }
}

export class StackB extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, cert: acm.ICertificate) {
    super(scope, id);

    new cdk.CfnOutput(this, 'CertArn', {
      value: cert.certificateArn
    });
  }
}

const app = new cdk.App();
const stackA = new StackA(app, 'StackA');
cdk.Tags.of(app).add('myTag', 'myValue');
new StackB(app, 'StackB', stackA.cert);

The Tags can actually be removed, you just need to specify the Certificate resource type, since that’s what the tags are labeled as:

cdk.Tags.of(app).remove('myTag', {
  includeResourceTypes: ['AWS::CertificateManager::Certificate'],
});

However, this doesn’t actually solve the problem. The IAM Policy and Lambda Function associated with the Custom Resource have changed, regardless of if tags are applied or not, which still causes the same issue. The same issue would present if the Lambda function was changed in any way at all (even adding a comment).

The real solution is likely to make the Lambda function smarter; currently, the on “Update”, the function still just requests a new certificate. If the actual properties of the certificate haven’t changed, this should be a no-op; if only tags have changed, we should be able to add/remove tags intelligently.

This is the relevant bit of the code that’s not intelligent enough yet:

https://github.com/aws/aws-cdk/blob/46a16312825cc7b5bf985bc8b69146a1397690d0/packages/@aws-cdk/aws-certificatemanager/lambda-packages/dns_validated_certificate_handler/lib/index.js#L246-L256

The solution here will likely involve comparing the event.ResourceProperties and event.OldResourceProperties (see the docs) on Update, and then taking the right next steps based on that.

It seems like this issue impacts a significant number of customers, and I’ve tagged it as P1, which means it should be on our near-term roadmap. If anyone is interested in taking a stab at the fix, I’d be more than happy to work with you. If you are able, we encourage you to contribute a bug fix.