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.
Creating cloud front and adding the domains.
After linking domains with cloud front we are requesting SSL from Let’s encrypt.
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.
Deploy the DNS validation acm-validations.aws CNAMEs on the required domains.
Poil the certificate until it is issued
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.
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
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.
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.
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.
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.
