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

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.

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

Jagjit Singh

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 with ValidationMethod=DNS
  2. Call ACM.DescribeCertificate with the ARN from the above, fetch the DNS challenges
  3. Deploy the DNS validation 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.


@_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

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.

1 Like

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

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.


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

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?


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

@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.


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.

1 Like

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

Value: token or keyauth

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

Calculating the TXT value is described at .

Basically, it is:


and key_authorization is described here: (same as for HTTP-01 challenge).

1 Like

@_az totally aggreed. still it shows pending status. Can you please check this

I did below input:

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.

Pending means you have not responded to the challenge, 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.

1 Like

@_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 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

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

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

1 Like

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

@_az I am using C# Certes.Acme. With that, I want to retrieve the details for the challenge from URL

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("");
        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.

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