Challenge failed: A/AAAA records don't contain IP address

My domains are: greendept.com, testify4love.org, testify4love.com

I ran this command: sudo certbot
It produced this output:

Performing the following challenges: http-01 challenge for greendept.com
http-01 challenge for testify4love.com
http-01 challenge for testify4love.org  
http-01 challenge for www.greendept.com
http-01 challenge for www.testify4love.com 
http-01 challenge for www.testify4love.org
Waiting for verification... Challenge failed for domain testify4love.com
Challenge failed for domain www.testify4love.com
http-01 challenge for testify4love.com
http-01 challenge for www.testify4love.com
Cleaning up challenges Some challenges have failed. IMPORTANT NOTES: - The following errors were reported by the server: Domain: testify4love.com 
 Type: unauthorized Detail: Invalid response from [https://testify4love.com/.well-known/acme-challenge/8W5lCczmyaR5ZLVfQ1Am_48QhMt9y1EXZNxmjQ9y0aY ](https://testify4love.com/.well-known/acme-challenge/8W5lCczmyaR5ZLVfQ1Am_48QhMt9y1EXZNxmjQ9y0aY) [2600:9000:20e9:6600:14:9b04:8440:93a1]: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"[http://www.w3.org/TR/html4/loose.dtd\ ](http://www.w3.org/TR/html4/loose.dtd/)">\n<HTML><HEAD><META HTTP-EQ" Domain: www.testify4love.com  Type: unauthorized Detail: Invalid response from [https://www.testify4love.com/.well-known/acme-challenge/OnWRlKfCFqWDAEtf-N1j00wqZwLtT3rPDBrcWapwVdQ ](https://www.testify4love.com/.well-known/acme-challenge/OnWRlKfCFqWDAEtf-N1j00wqZwLtT3rPDBrcWapwVdQ) [2600:9000:20e9:6600:14:9b04:8440:93a1]: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"[http://www.w3.org/TR/html4/loose.dtd\ ](http://www.w3.org/TR/html4/loose.dtd/)">\n<HTML><HEAD><META HTTP-EQ"
To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. 

My web server is (include version): Apache/2.4.39

The operating system my web server runs on is (include version): Amazon Linux 2 AMI (running on an EC2 instance)

My hosting provider, if applicable, is: Amazon Web Services

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): Amazon console

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

certbot 0.38.0

============
The error message is telling me to make sure that the DNS A/AAAA records for the domain that failed (testify4love.com) contain the right IP address.

But in Route 53 these A and AAAA records are aliased to Cloudfront, so don’t have any IP address. Should I temporarily change Route 53 A/AAAA records for testify4love.com to the EC2 IP address, create the certificates, and then change the A and AAAA records back to Cloudfront? Or how should I proceed?

Can you post the rest of Certbot’s output?

In CloudFront, how is the Origin Protocol Policy set? Is CloudFront contacting your origin over HTTP or over HTTPS?

You’re really using 0.38.0? That’s not a typo of 0.28.0, is it?

My first guess about what might be happening should be fixed as of Certbot 0.31.0.

No. For one thing, you’d have to repeat that every time you renewed the certificate. It’s possible to fix things so that it will work with CloudFront.

Hi @mikeh1

not really. The A/AAAA info is a general information. Your detailed error:

Invalid response from https://testify4love.com/.well-known/acme-challenge/8W5lCczmyaR5ZLVfQ1Am_48QhMt9y1EXZNxmjQ9y0aY [2600:9000:20e9:6600:14:9b04:8440:93a1]: “\n<META HTTP-EQ” Domain: www.testify4love.com Type: unauthorized Detail: Invalid response from https://www.testify4love.com/.well-known/acme-challenge/OnWRlKfCFqWDAEtf-N1j00wqZwLtT3rPDBrcWapwVdQ [2600:9000:20e9:6600:14:9b04:8440:93a1]: “\n<META HTTP-EQ”

So Letsencrypt has found an AAAA record, but the content of your validation file is wrong.

What’s your internal ip address?

What says

apachectl -S

You have a redirect http -> https, but there is no older certificate with that domain name ( https://check-your-website.server-daten.de/?q=testify4love.com ):

Issuer not before not after Domain names LE-Duplicate next LE
Amazon 2019-09-28 2020-10-29 testify4love.com, www.testify4love.com
2 entries
cPanel, Inc. Certification Authority 2018-07-19 2018-10-18 mail.testify4love.com, testify4love.com, testify4love.greendept.org, www.testify4love.com, www.testify4love.greendept.org
5 entries
cPanel, Inc. Certification Authority 2018-05-04 2018-08-03 mail.testify4love.com, testify4love.com, testify4love.greendept.org, www.testify4love.com, www.testify4love.greendept.org
5 entries

Looks like the wrong vHost answers (the default https vHost).

What’s your authenticator? --apache or --webroot? --apache should add a location definition, then there would be no redirect visible. But Letsencrypt sees the redirect -> Certbot doesn’t understand your configuration.

1 Like

In this case, the redirect is generated by Cloudfront and the initial request never reaches the origin server:

X-Cache: Redirect from cloudfront

But as @mnordhoff mentioned, the Apache authenticator in Certbot >= 0.31.0 puts the challenge response rule into both HTTP and HTTPS virtualhosts, so it should work in theory.

2 Likes

Actually…

Why do you want to issue a testify4love.com or www.testify4love.com certificate? What do you want to use it for?

https://testify4love.com/ and https://www.testify4love.com/ already use a valid certificate issued by Amazon.

Your origin should have a certificate to secure the connection between itself and CloudFront, but that would be for a different hostname, AIUI – the Origin Domain Name.

1 Like

Thanks for your help, @mnordhoff and @JuergenAuer!

I do see that when I go to testify4love.com, it says it has a valid certificate. I did create such a certificate when I created the Cloudfront distribution. But I thought to secure the website on the EC2 instance I would need a certificate on the EC2 instance.

I wanted to issue a Letsencrypt certificate because I understood that, when I install a website on an Amazon EC2 instance, I cannot directly deploy an ACM Certificate on that instance. Instead, I can deploy a third party certificate on the EC2 instance. But perhaps I misunderstand the implications of this?

To answer other questions, in case that is still useful:

I believe the only other output from certbot was:

 - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will  also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.

Origin Protocol Policy is “HTTP Only”

certbot is really truly 0.38.0!

internal IP is 172.31.40.8 but I believe this could change if I stop and restart the EC2? I’m curious why you asked about this.

apachectl -S

[Thu Oct 10 13:10:35.897812 2019] [so:warn] [pid 31314] AH01574: module rewrite_module is already loaded, skipping
VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server testify4love.com (/etc/httpd/conf/httpd.conf:165)
         port 80 namevhost testify4love.com (/etc/httpd/conf/httpd.conf:165)
                 alias www.testify4love.com
         port 80 namevhost greendept.com (/etc/httpd/conf/httpd.conf:176)
                 alias www.greendept.com
         port 80 namevhost testify4love.org (/etc/httpd/conf/httpd.conf:187)
                 alias www.testify4love.org
*:443                  ip-172-31-40-8.us-west-2.compute.internal (/etc/httpd/conf.d/ssl.conf:56)
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex lua-ivm-shm: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/run/httpd/" mechanism=default 
Mutex mpm-accept: using_defaults
Mutex cache-socache: using_defaults
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
PidFile: "/run/httpd/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="apache" id=48 not_used
Group: name="apache" id=48 not_used

You’re right. :smile:

What’s the Origin Domain Name set to?

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