-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(certificatemanager): native CloudFormation DNS validated certificate #8552
Conversation
…cate Automatically adding Amazon Route 53 CNAME records for DNS validation is now natively supported by CloudFormation. Add a `validation` prop to `Certificate` to handle both email and DNS validation. Deprecate `DnsValidatedCertificate`. The default remains email validation (non-breaking). Closes aws#5831 Closes aws#5835 Closes aws#6081 Closes aws#6516 Closes aws#7150 Closes aws#7941 Closes aws#7995 Closes aws#7996
What should be done here?
If we replace See also aws-cloudformation/cloudformation-coverage-roadmap#523 |
Any news on this? Recently a lot of |
```ts | ||
new Certificate(this, 'Certificate', { | ||
domainName: 'hello.example.com', | ||
validation: CertificateValidation.fromDns(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the README here should call out the same warning from the fromDns
documentation about needing to manually add the DNS records before CloudFormation can succeed. Might even be worth having the Route53 example first (as the thing people are most likely to copy/paste and use), and then call out the outside-DNS example with the warning about the need for manual intervention.
* @deprecated use the `validation` prop with `CertificateValidation.fromDns()` | ||
* on `Certificate`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Counter-argument -- this custom resource-based approach allows for cross-region cert creation, which the native CloudFormation support doesn't allow (AFAIK). It might be worth not deprecating it, and noting this use case in the README. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. For information, it's in the CF roadmap aws-cloudformation/cloudformation-coverage-roadmap#523.
This also solves my question here #8552 (comment)
* @param hostedZone the default hosted zone to use for all domains in the certificate | ||
* @param hostedZones a map of hosted zones to use for domains in the certificate | ||
*/ | ||
public static fromDns(hostedZone?: route53.IHostedZone, hostedZones?: { [domainName: string]: route53.IHostedZone }) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to think of a better way to do this interface. As-is, it's not clear how to use it -- if I need to provide the hostedZones
map, do I also need to provide the hostedZone
? If so, does it matter which is the "main" zone and which appears in the map? One other thought -- domain names to hosted zones are N:1; you may have 10 domain names with two top-level hosted zones; flipping the map around may be slightly more usable for some customers (I don't have the data to back that up off-hand though).
Maybe breaking this into two would alleviate some of the problems:
public static fromDns(hostedZone?: route53.IHostedZone) {...}
public static fromDnsMultiZone(hostedZoneMap: { [domainName: string]: route53.IHostedZone) {...}
Open to better naming and disagreements.
Use the `DnsValidatedCertificate` construct for cross-region certificate creation: | ||
|
||
```ts | ||
new DnsValidatedCertificate(this, 'CrossRegionCertificate', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do:
export class CrossRegionDnsValidatedCertificate extends DnsValidatedCertificate {
constructor(scope: cdk.Construct, id: string, props: DnsValidatedCertificateProps) {
super(scope, id, props);
}
}
to get a better naming?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's worth it, especially considering cross-region support is on the roadmap for CloudFormation. Let's just leave it as-is and deprecate it once we can.
@@ -1,26 +0,0 @@ | |||
import * as route53 from '@aws-cdk/aws-route53'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you un-delete this file, given we are not (yet) deprecating the DnsValidatedCertificate?
@njlynch can you re-approve? |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Automatically adding Amazon Route 53 CNAME records for DNS validation is
now natively supported by CloudFormation.
Add a
validation
prop toCertificate
to handle both email and DNSvalidation.
DnsValidatedCertificate
is now only useful for cross-regioncertificate creation.
The default remains email validation (non-breaking).
Closes #5831
Closes #5835
Closes #6081
Closes #6516
Closes #7150
Closes #7941
Closes #7995
Closes #7996
Closes #8282
Closes #8659
Closes #8783
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license