# Troubles with HTTP verification via CloudFront + S3 **URL:** \ **Category:** Help\ **Created:** [February 3, 2020, 12:43pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188 "2020-02-03T12:43:23Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![RuslanV](https://avatars.discourse-cdn.com/v4/letter/r/5daacb/32.png) [@RuslanV](https://community.letsencrypt.org/u/RuslanV)\ **Post date:** [February 3, 2020, 12:43pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/1 "2020-02-03T12:43:23Z")
My domain is: magetest.cf I ran this command: curl -XGET [http://magetest.cf/.well-known/acme-](http://magetest.cf/.well-known/acme-) challenge/5SH1d5GetURvg4wexDAtNMUjxWYMZk4q4K-IfgWWOuM It produced this output: 5SH1d5GetURvg4wexDAtNMUjxWYMZk4q4K-IfgWWOuM.Gy2PF66rEjQusCGhKWHm2ddrBIp9vmikm38eyhOo57M My web server is (include version): CloudFront pointed to S3 The operating system my web server runs on is (include version): CloudFront pointed to S3 My hosting provider, if applicable, is: DNS zone is in Cloudflare, A records are pointed to CloudFront distribution with **.well-known** path backed by S3 bucket configured as a static website. I can login to a root shell on my machine (yes or no, or I don’t know): no In CloudFront logs we can see the following: 2020-02-03 12:21:27 DEN50-C2 533 66.133.109.36 GET [d1po0h3exnpx3a.cloudfront.net](http://d1po0h3exnpx3a.cloudfront.net) /.well-known/acme-challenge/5SH1d5GetURvg4wexDAtNMUjxWYMZk4q4K-IfgWWOuM 200 - Mozilla/5.0%20(compatible;%20Let’s%20Encrypt%20validation%20server;%20+https://www.letsencrypt.org) - - Miss tOLRS1HU5zYUOjtfDlY4JrRr019m6oWjrkhbp8820uckvYjIm9jTBw== magetest.cf http 263 0.104 - - - Miss HTTP/1.1 - - 27916 0.104 Miss text/plain 87 - - Same log entry for curl: 2020-02-03 12:22:25 TXL52-C1 538 93.72.107.17 GET [d1po0h3exnpx3a.cloudfront.net](http://d1po0h3exnpx3a.cloudfront.net) /.well-known/acme-challenge/5SH1d5GetURvg4wexDAtNMUjxWYMZk4q4K-IfgWWOuM 200 - curl/7.58.0 - - Miss sShFiNDpwEJTAFCRhYMhq0QxlffV7OoX8-0UU-0dJTDvoJZ9uVgbOg== magetest.cf http 145 0.105 - - - Miss HTTP/1.1 - - 57180 0.105 Miss text/plain 87 - - ---
**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:** [February 3, 2020, 12:51pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/2 "2020-02-03T12:51:58Z")
What problems are you having? ---
**Author:** ![RuslanV](https://avatars.discourse-cdn.com/v4/letter/r/5daacb/32.png) [@RuslanV](https://community.letsencrypt.org/u/RuslanV)\ **Post date:** [February 3, 2020, 1:02pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/3 "2020-02-03T13:02:24Z")
Trying to renew SSL certificate via HTTP. I’m using [https://github.com/certbot/certbot/tree/master/acme/](https://github.com/certbot/certbot/tree/master/acme/), version is 1.0.0 I’m using ClientV2. The error occurs on **answer\_challenge** stage for HTTP01 challenge The error I get is: urn:ietf:params:acme:error:malformed :: The request message was malformed :: No such challenge ---
**Author:** ![stevenzhu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/stevenzhu/32/18864_2.png) [@stevenzhu](https://community.letsencrypt.org/u/stevenzhu)\ **Post date:** [February 3, 2020, 3:03pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/4 "2020-02-03T15:03:14Z")
Hi, If you are using Cloudfront and S3 storage as your source. You should consider using ACM (AWS Certificate Manager) issued certificates. Uploading Let’s Encrypt certificate to ACM (you’ll need to do that if you use Cloudfront) every 2 months are painful and ACM certificates serves better if you use Cloudfront or ELB in AWS. Read more about ACM here: [https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) The steps needed to request a free ACM certificate is described in ACM’s documentation: [https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) Thank you ---
**Author:** ![RuslanV](https://avatars.discourse-cdn.com/v4/letter/r/5daacb/32.png) [@RuslanV](https://community.letsencrypt.org/u/RuslanV)\ **Post date:** [February 3, 2020, 3:39pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/5 "2020-02-03T15:39:18Z")
Hello, Basically, I need an option to renew/issue the certificate with HTTP verification. AFAIK ACM supports only DNS and email verification. Thanks ---
**Author:** ![stevenzhu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/stevenzhu/32/18864_2.png) [@stevenzhu](https://community.letsencrypt.org/u/stevenzhu)\ **Post date:** [February 3, 2020, 4:34pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/6 "2020-02-03T16:34:13Z")
Hi, I understand this, but it would be exceptionally hard to use S3 + Cloudflare with certbot (you might need to spend a long time between putting the files and complete challenge). May I know why you want to use HTTP validation? Based on your description and setup, you can easily use DNS validation for both Let's Encrypt and ACM. Many programs allow you to use Cloudflare API to issue the Let's Encrypt certificate. DNS validation for ACM is also easy since the DNS records is the same for every renewal (in ACM), which means you don't need to update DNS records every renewal. > [@RuslanV](#): > > urn:ietf:params:acme:error:malformed :: The request message was malformed :: No such challenge This means your challenge does not exist.... Thank you ---
**Author:** ![RuslanV](https://avatars.discourse-cdn.com/v4/letter/r/5daacb/32.png) [@RuslanV](https://community.letsencrypt.org/u/RuslanV)\ **Post date:** [February 3, 2020, 5:26pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/7 "2020-02-03T17:26:29Z")
Hello, The problem is that we don’t actually have full control on DNS. We’ve implemented a full lifecycle for issuing/renewing SSL certificates from LetsEncrypt via DNS01+HTTP01 challenges and further import to ACM. It worked fine for some time. I guess we’ve started facing the described HTTP verification issues after ACMEv1 end of life. Thanks ---
**Author:** ![RuslanV](https://avatars.discourse-cdn.com/v4/letter/r/5daacb/32.png) [@RuslanV](https://community.letsencrypt.org/u/RuslanV)\ **Post date:** [February 4, 2020, 9:29am UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/8 "2020-02-04T09:29:22Z")
Hello, The trouble is that LetsEncrypt actually hits CloudFront and receives 200 status. Also, CloudFront shows connection closure. Still, LetsEncrypt **answer\_challenge** endpoint raises an error. This info was obtained from CloudFront log entries: > 2020-02-03 12:21:27 DEN50-C2 533 66.133.109.36 GET [d1po0h3exnpx3a.cloudfront.net](http://d1po0h3exnpx3a.cloudfront.net/) /.well-known/acme-challenge/5SH1d5GetURvg4wexDAtNMUjxWYMZk4q4K-IfgWWOuM 200 - Mozilla/5.0%20(compatible;%20Let’s%20Encrypt%20validation%20server;%20+https://www.letsencrypt.org) - - Miss tOLRS1HU5zYUOjtfDlY4JrRr019m6oWjrkhbp8820uckvYjIm9jTBw== magetest.cf http 263 0.104 - - - Miss HTTP/1.1 - - 27916 0.104 Miss text/plain 87 - - Thanks ---
**Author:** ![gnuzealot](https://avatars.discourse-cdn.com/v4/letter/g/90ced4/32.png) [@gnuzealot](https://community.letsencrypt.org/u/gnuzealot)\ **Post date:** [February 5, 2020, 3:58pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/9 "2020-02-05T15:58:54Z")
Can we get an update on this ticket? We have nothing to go on as to why this would fail when the correct response is being sent from cloudfront. ---
**Author:** ![stevenzhu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/stevenzhu/32/18864_2.png) [@stevenzhu](https://community.letsencrypt.org/u/stevenzhu)\ **Post date:** [February 5, 2020, 4:37pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/10 "2020-02-05T16:37:33Z")
Hi, This is actually pretty clueless for me. The only issue I would suspect is that your timeout (time between deploy and propergration) isn’t long enough, so even if you’re seeing the response, some validation servers does not. ---
**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:** [February 5, 2020, 4:45pm UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/11 "2020-02-05T16:45:24Z")
Can you provide more information? Your code, debug logs? ---
**Author:** ![RuslanV](https://avatars.discourse-cdn.com/v4/letter/r/5daacb/32.png) [@RuslanV](https://community.letsencrypt.org/u/RuslanV)\ **Post date:** [February 6, 2020, 11:46am UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/12 "2020-02-06T11:46:36Z")
Hello, Looks pretty weird, but today I’ve managed to get the cert. I didn’t change the code, but another try resulted in “no DNS challenge” for the domain. I’ve added DNS challenge ignore and got the cert via HTTP verification. Looks like something has changed on LetsEncrypt side. Is there any changelog so we can validate code behavior change against it? Thanks. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [March 7, 2020, 11:46am UTC](https://community.letsencrypt.org/t/troubles-with-http-verification-via-cloudfront-s3/112188/13 "2020-03-07T11:46:37Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.