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