# Aws cloud front changed CNAME policy so need a new way to generate SSL with let's encrypt and use on Cloud front

**URL:** <https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694>\
**Category:** Help\
**Created:** [July 12, 2019, 5:56am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694 "2019-07-12T05:56:34Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 12, 2019, 5:56am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/1 "2019-07-12T05:56:34Z")

</div>

Hi Team

AWS cloud front has changed the policy for adding CNAMES, now they are not allowing to a custom domain without SSL certificate. Earlier we were using the below process.

1. Creating cloud front and adding the domains.
2. After linking domains with cloud front we are requesting SSL from Let’s encrypt.
3. As we already connected the domain to cf we are able to verify the domains with the content provided by lets’ encyrpt

But now, as mentioned we cannot add the domains until or unless we have SSL certificate on aws cloud front.

Is there is a way to verify the domains with txt record or any alternative to this solution? Below is the link that have details about the cloud front policy changed by aws.

> **[Continually Enhancing Domain Security on Amazon CloudFront | Amazon Web Services](https://aws.amazon.com/blogs/networking-and-content-delivery/continually-enhancing-domain-security-on-amazon-cloudfront/)**
>
> Last year, a colleague of mine wrote a blog post about new security measures that Amazon CloudFront was implementing to enhance the security of how domains are used on CloudFront distributions. This included mitigations to prevent the abusive use of...

@cpu @JuergenAuer can you please check it and help me here if you can.

Thanks,  
Jagjit Singh

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [July 12, 2019, 6:32am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/2 "2019-07-12T06:32:33Z")

</div>

Why does Let’s Encrypt need to be involved?

You can request a free certificate for use in Cloudfront from ACM, using DNS to solve the domain validation.

1. Call [`ACM.RequestCertificate`](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html) with `ValidationMethod=DNS`
2. Call [`ACM.DescribeCertificate`](https://docs.aws.amazon.com/acm/latest/APIReference/API_DescribeCertificate.html) with the ARN from the above, fetch the DNS challenges
3. Deploy the DNS validation `acm-validations.aws` CNAMEs on the required domains.
4. Poil the certificate until it is issued
5. Create the CF distribution/add the alternate names to the distribution.

I’m not sure what problem is solved or value is added by using Let’s Encrypt. It seems like a strictly worse solution, since ACM would then provide continual renewal without any external processing.

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 12, 2019, 7:42am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/3 "2019-07-12T07:42:38Z")

</div>

@_az due to some reasons we cannot use the ACM as that is limited to a number of domains per certificate. More over our clients may add new domains and delete domains so that is really tough to manage with ACM

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [July 12, 2019, 7:44am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/4 "2019-07-12T07:44:40Z")

</div>

ACM and Let’s Encrypt have the same maximum limit of names per certificate - 100.

If you fill in the rate limit increase form in AWS explaining that you plan to use DNS validation, I’m sure they will raise it to 100 for you.

I don’t really see the difference between using ACME DNS validation and ACM DNS validation, the management overhead seems identical. But if you really want to use Let’s Encrypt with DNS validation, there’s nothing stopping you.

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 12, 2019, 7:49am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/5 "2019-07-12T07:49:23Z")

</div>

That’s fine but in that way everytime a user deletes/add domain we need to request new certificate and that require user intervention to prove the domain owner-ship. With let’s encrypt we can use http method in a very good manner and that is not taking much time. We only want let’s encrypt and we build it in this way already but now they have changed policy we cannot add the DOMAINS without SSL that means we cannot use let’s encrypt http method as domain cannot be binded up with cf

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [July 12, 2019, 7:58am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/6 "2019-07-12T07:58:16Z")

</div>

It seems to me that you are going to require some form of user intervention either way, before Cloudfront allows you to add new names.

Let’s Encrypt DNS validation requires the domain owner to create a TXT record before a certificate can be issued.

ACM DNS validation requires the domain owner to create a CNAME record before the certificate can be issued.

If the domain owner delegates their entire zone to you that would let you automate it yourself, but that’s just another form of user intervention.

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [July 12, 2019, 6:02pm UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/7 "2019-07-12T18:02:30Z")

</div>

This is a bit of a confusing issue so I'm copying some of Amazon's linked documentation directly:

> [@](#):
>
> ### Securely adding alternate domain names (CNAMEs) with CloudFront
> 
> Before diving into the details, it is important to clarify that a CloudFront alternate domain name (CNAME) is not the same thing as the authoritative DNS domain name or canonical name, also known as a CNAME. These two entries are related by nature of establishing a link between two different entities, but each entry is separate and distinct from each other. The CloudFront alternate domain name (CNAME) on a CloudFront distribution allows you to serve your content using a custom [CNAME](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) from your DNS records, such as [www.example.com](http://www.example.com), instead of the default domain that CloudFront assigns, such as [d123456abcdef8.cloudfront.net](http://d123456abcdef8.cloudfront.net). Only the CNAME from your authoritative DNS records actually controls where your domain’s traffic is pointed to and from which endpoint your traffic will be served to your end users.
> 
> When adding an alternate domain name to CloudFront, we have always checked that the CNAME did not already exist on another distribution, or that it did not fall under the umbrella of a wildcard alternate domain name that exists in another account’s distribution. If the alternate domain name is not available for either one of these [reasons](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions), customers are asked to [contact](https://aws.amazon.com/premiumsupport/knowledge-center/resolve-cnamealreadyexists-error/) AWS Support and prove ownership of their domain. This is done by the customer creating a new DNS TXT record entry before they are given rights to use that alternate domain name.
> 
> Today’s change further enhances the security of CloudFront’s domain validation process. Starting today, when you add an alternate domain name by using the AWS Management Console or the CloudFront API, you must also attach a SSL/TLS certificate to that specific distribution in order to validate that you have authorized rights to use that alternate domain name. This is designed to ensure that only customers with authorized access to a domain’s certificate can add alternate domain names to use with a CloudFront distribution.
> 
> ### New validation checks when adding an alternate domain name
> 
> ...
> 
> CloudFront’s process to validate a customer’s right to use an alternate domain name builds on the already established and trusted checks in place for obtaining a certificate. ... Rather than having customers go through a redundant process to re-validate their ownership, CloudFront will now simply require that a certificate be attached to that distribution when adding an alternate domain name to the distribution.
> 
> This certificate must be ... issued by a publicly trusted Certificate Authority (CA), such as ACM. If you do not choose to use ACM, any certificate issued from a CA listed on the [Mozilla Included CA Certificate List](https://wiki.mozilla.org/CA/Included_Certificates) will work as well. The certificate must also include the alternate domain name being added to the distribution in the subject alternate name (SAN) field of the certificate – either by an explicit match, or a wildcard at the same level of the alternate domain name being added.

So, you can generate a Let's Encrypt certificate, and them use that to prove to Cloudfront that you control the given domain name.

However, it sounds like you were probably having your customers delegate their DNS to Cloudfront _before_ issuing a certificate. That won't work anymore. You'll need to have your customers delegate their DNS to a domain that you operate, and then you can delegate onwards to Cloudfront once you've issued a certificate.

I'll also note that if you are managing large certificates with many names on them, it will make many things difficult. I strongly recommend issuing a single certificate per domain name. That makes the issue of adding and removing names easier.

Also, it sounds like this is a recent change from Amazon and you are a paying customer. I suspect they will be very eager to ensure that your setup continues to work. Have you contacted Amazon support?

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 15, 2019, 6:11am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/8 "2019-07-15T06:11:51Z")

</div>

> [@jsha](#):
>
> f a confusing issue so I’m copying some of Amazon’s linked documentation directly:

Thnaks @jsha thanks for your update. I already aware about this change from aws. I think now we have to proceed with let's encrypt first with txt record validation and after getting ssl approaval will have to update the cloud front with the newly cname secured by let's encryppt

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 15, 2019, 8:07am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/9 "2019-07-15T08:07:37Z")

</div>

@jsha @_az can you help me how I have to use the dns validation. I am getting token and keyauth. How i need to add it in the TXT record ? Do I need to add the token as host value and keyauth as value for the TXT record.

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [July 15, 2019, 8:12am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/10 "2019-07-15T08:12:14Z")

</div>

No.

> **[RFC 8555: Automatic Certificate Management Environment (ACME)](https://datatracker.ietf.org/doc/html/rfc8555)**
>
> Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an...

> A client fulfills this challenge by constructing a key authorization  
> from the "token" value provided in the challenge and the client's  
> account key. The client then computes the SHA-256 digest [FIPS180-4]  
> of the key authorization.
> 
> The record provisioned to the DNS contains the base64url encoding of  
> this digest. The client constructs the validation domain name by  
> prepending the label "\_acme-challenge" to the domain name being  
> validated, then provisions a TXT record with the digest value under  
> that name.

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 15, 2019, 8:15am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/11 "2019-07-15T08:15:32Z")

</div>

@mnordhoff thanks for your response. Based on this i got this

Host: \_acme-challenge.mydomain.com  
Value: token or keyauth

Please confirm what should be the value for the “Value” field of txt record.

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [July 15, 2019, 8:25am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/12 "2019-07-15T08:25:48Z")

</div>

Calculating the TXT value is described at [https://tools.ietf.org/html/rfc8555#section-8.4](https://tools.ietf.org/html/rfc8555#section-8.4) .

Basically, it is:

```
base64url(sha256(key_authorization))

```

and `key_authorization` is described here: [https://tools.ietf.org/html/rfc8555#section-8.1](https://tools.ietf.org/html/rfc8555#section-8.1) (same as for HTTP-01 challenge).

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 15, 2019, 8:49am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/13 "2019-07-15T08:49:29Z")

</div>

@_az totally aggreed. still it shows pending status. Can you please check this  
[https://acme-v02.api.letsencrypt.org/acme/challenge/e49fzCAXOlTLYoUVFJCRIOMT-ZWXPlJa7\_rJ-WAFBQw/18296535329](https://acme-v02.api.letsencrypt.org/acme/challenge/e49fzCAXOlTLYoUVFJCRIOMT-ZWXPlJa7_rJ-WAFBQw/18296535329)

I did below input:

Host: \_acme-challenge.localprodtest.hiremytrainer.com  
value: HTZEhmzm-cXcRXRPVVRUo8Uw2BFLiUuz3\_r43k\_Khlg.Q9Q0MLNOhNpVf8pUPpTUP78u5w36lWKS5auwbnbcyNk

Please let me know if i did any mistake here or anything I need to change in the DNS record.

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [July 15, 2019, 8:51am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/14 "2019-07-15T08:51:44Z")

</div>

Pending means you have not [responded to the challenge](https://tools.ietf.org/html/rfc8555#section-7.5.1), so Let's Encrypt doesn't know that it needs to check for the completion of the challenge.

> the client needs to provision the required challenge response based on  
> the challenge type and indicate to the server that it is ready for  
> the challenge validation to be attempted.

Are you trying to do this by hand? Your ACME client should be doing this for you, including calculating the DNS TXT record.

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 15, 2019, 8:53am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/15 "2019-07-15T08:53:42Z")

</div>

@_az i am doing it manually and i am not using any client. Please help me to complete the process manually. I am trying myselft to ping the URL [https://acme-v02.api.letsencrypt.org/acme/challenge/e49fzCAXOlTLYoUVFJCRIOMT-ZWXPlJa7\_rJ-WAFBQw/18296535329](https://acme-v02.api.letsencrypt.org/acme/challenge/e49fzCAXOlTLYoUVFJCRIOMT-ZWXPlJa7_rJ-WAFBQw/18296535329) enforcing let’s encrypt to verify it.

Once I am done with manually process then I will write a job to ping the requesting challenge. Also FYI- I am using the DNS challenge

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [July 15, 2019, 8:55am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/16 "2019-07-15T08:55:08Z")

</div>

Sorry dude, you’re just taking blind stabs in the dark. As written in the spec. You can’t do this manually because you need to send cryptographically signed POST requests to the server. It’s impossible to do it by hand.

Either read the spec properly or get an ACME client that has implemented it properly.

For example, with Certbot:

```
certbot certonly -a manual --preferred-challenges dns -d example.org

```

will tell you all of the TXT records, will wait for you to deploy them, will respond to the challenge for you as well.

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 15, 2019, 8:57am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/17 "2019-07-15T08:57:06Z")

</div>

@_az thanks for your help. Let me do it via client request 🙂

---

<div class="post-metadata">

**Author:** ![Jagjit](https://avatars.discourse-cdn.com/v4/letter/j/4491bb/32.png) [@Jagjit](https://community.letsencrypt.org/u/Jagjit)\
**Post date:** [July 15, 2019, 10:31am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/18 "2019-07-15T10:31:18Z")

</div>

@_az I am using C# **Certes.Acme.** With that, I want to retrieve the details for the challenge from URL [https://acme-v02.api.letsencrypt.org/acme/challenge/e49fzCAXOlTLYoUVFJCRIOMT-ZWXPlJa7\_rJ-WAFBQw/18296535329](https://acme-v02.api.letsencrypt.org/acme/challenge/e49fzCAXOlTLYoUVFJCRIOMT-ZWXPlJa7_rJ-WAFBQw/18296535329)

but I am not getting anything in the result so that I an validate the details. I tried below:  
var keytDetails = KeyFactory.FromPem(pemKey);

```
        var accountPemKey = keytDetails.ToPem();

        var acme = new AcmeContext(WellKnownServers.LetsEncryptV2, keytDetails);

        var uri = new Uri("https://acme-v02.api.letsencrypt.org/acme/challenge/e49fzCAXOlTLYoUVFJCRIOMT-ZWXPlJa7_rJ-WAFBQw/18296535329");
        var order = acme.Order(uri);
        var authorizationDetails = acme.Authorization(uri);
       
        var challenges = await authorizationDetails.Challenges();

```

Is there is any way to retrieve the challenge details so that I can gry for the validation.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [August 14, 2019, 10:31am UTC](https://community.letsencrypt.org/t/aws-cloud-front-changed-cname-policy-so-need-a-new-way-to-generate-ssl-with-lets-encrypt-and-use-on-cloud-front/97694/19 "2019-08-14T10:31:20Z")

</div>

Closed on August 14, 2019, 10:31am UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.