AWS::CertificateManager::Certificate DNS Validation Return Values
New return value. When performing DNS Validation of certificate names it would be useful to have return values for the subdomain and value. Boto3 already returns this when requesting a new certificate : https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/acm.html#ACM.Client.request_certificate (look for ResourceRecord) This is useful for providing either an Output for the stack or being referenced inside the stack it's self to create the record for DNS validation.
Example usage could be:
mycert:
Type: AWS::CertificateManager::Certificate
Properties:
DomainName: example.com
DomainValidationOptions:
- DomainName: example.com
ValidationDomain: example.com
myDNSRecord:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneName: !Ref 'HostedZoneResource'
Name: !GetAtt mycert.DNSValidationName
Type: CNAME
TTL: '900'
ResourceRecords:
- !GetAtt mycert.DNSValidationValue
Related #31
This exists as part of the CDK. Not a CFN resource lambda, but could easily be adapted (https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-certificatemanager/lambda-packages/dns_validated_certificate_handler/lib/index.js)
I use one CFN Python resource that is released under Apache 2.0 license by AWS Labs as part of one of the AWS solutions: https://github.com/OHDSI/OHDSIonAWS/blob/master/01-certificate-ohdsi.yaml
I think this issue is still relevant and this function is still needed, despite the fact that CloudFormation can now create validation DNS records if the domain is hosted in Route 53. This is because there are many of us whose domains are not, and will not be, hosted in Route 53. Or, some of us are writing templates for consumption by those who may or may not have their domains hosted in Route 53, but we don't want to make that a requirement. Adding a HostedZoneId property that is not filled in will cause the template to fail.
In short, many users are stuck with manually creating DNS records for validation, but we shouldn't have to dig through the stack events (or write documentation explaining to end users how to do that) for the records that need to be created. This should be made visible through a template output, by providing some way to return or look up the records.
This is still needed for us, in the early stages of a transition from CloudFlare to Route53/ACM, to feed our custom resource provider for CloudFlare CNAME records until we can get our NS moved over
It's interesting how much time I'm investing reading documentation and forums about this topic, without a simple outcome. Creating (and managing) a Lambda function sounds "out of scope", but I can't find any other way to validate an ACM certificate using Route53's DNS.
It's interesting how much time I'm investing reading documentation and forums about this topic, without a simple outcome. Creating (and managing) a Lambda function sounds "out of scope", but I can't find any other way to validate an ACM certificate using Route53's DNS.
this solutions works , https://stackoverflow.com/questions/76847880/acm-certificate-validation-failure-from-cloudformation-templa
I'm sorry, @midhunco, I never came back here to rectify: my problem was that ACM only automatically validate a certificate using Route53's DNS when using us-east-1 region. I was trying to use eu-central-1. Unless something has changed over the year, I stick creating the certificates on American region to have the validation automatically done via Route53's CNAME records.
Tip: it takes a bit time and requires the steps on CloudFormation to be chained and dependable to create the CNAME records and validate the certificate.