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

My domains are:,,

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

Performing the following challenges: http-01 challenge for
http-01 challenge for
http-01 challenge for  
http-01 challenge for
http-01 challenge for 
http-01 challenge for
Waiting for verification... Challenge failed for domain
Challenge failed for domain
http-01 challenge for
http-01 challenge for
Cleaning up challenges Some challenges have failed. IMPORTANT NOTES: - The following errors were reported by the server: Domain: 
 Type: unauthorized Detail: Invalid response from [ ]( [2600:9000:20e9:6600:14:9b04:8440:93a1]: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"[\ ](">\n<HTML><HEAD><META HTTP-EQ" Domain:  Type: unauthorized Detail: Invalid response from [ ]( [2600:9000:20e9:6600:14:9b04:8440:93a1]: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"[\ ](">\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 ( 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 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 [2600:9000:20e9:6600:14:9b04:8440:93a1]: “\n<META HTTP-EQ” Domain: Type: unauthorized Detail: Invalid response from [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 ( ):

Issuer not before not after Domain names LE-Duplicate next LE
Amazon 2019-09-28 2020-10-29,
2 entries
cPanel, Inc. Certification Authority 2018-07-19 2018-10-18,,,,
5 entries
cPanel, Inc. Certification Authority 2018-05-04 2018-08-03,,,,
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.



Why do you want to issue a or certificate? What do you want to use it for? and 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, 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 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 (/etc/httpd/conf/httpd.conf:165)
         port 80 namevhost (/etc/httpd/conf/httpd.conf:165)
         port 80 namevhost (/etc/httpd/conf/httpd.conf:176)
         port 80 namevhost (/etc/httpd/conf/httpd.conf:187)
*:443         (/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/"
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.