Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
[redacted]
I ran this command:
certbot renew
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for [redacted]
Waiting for verification…
Cleaning up challenges
Attempting to renew cert ([redacted]) from /etc/letsencrypt/renewal/[redacted].conf produced an unexpected error: Failed authorization procedure. [redacted] (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://[redacted]/.well-known/acme-challenge/rv3491PbwHWwAraSQv1SXHJcWmPM-BEsvWzR2QQD7zA: Timeout during connect (likely firewall problem). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/[redacted]/fullchain.pem (failure)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/[redacted]/fullchain.pem (failure)
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. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
My web server is (include version):
Apache version 2.4.18
The operating system my web server runs on is (include version):
Ubuntu Linux 16.04
My hosting provider, if applicable, is:
Amazon ec2
I can login to a root shell on my machine (yes or no, or I don’t know):
Yes I can
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
webmin
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.28.0
It looks like you do have a firewall blocking connections on port 80, which is preventing the validation from succeeding. Could this be in your Amazon EC2 policies? They often have defaults that block quite a lot of ports.
You might also want to use Webmin's built-in Let's Encrypt support instead of Certbot (although that won't fix the firewall problem, which would affect Webmin just as much as Certbot).
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. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you’re using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.
[continuation of log redacted]
It still looks filtered by a firewall to me from here. You should check for both host and network firewalls (like both ufw and policy groups), because either can interfere with connections.
There is a change related to limiting the use of port 443 in validations which was announced in January of last year and formally scheduled in October of last year.
In order to prepare for this change, Certbot's default behavior was changed in releases starting last month:
It's something of an oversimplification to say "port 80 was not used before", but it's true that there's been a recent change which has meant that Certbot users who were validating over port 443 have been switched to validating over port 80. We've been trying to accelerate this process because in the near future the Let's Encrypt certificate authority will disable TLS-SNI-01 validations entirely, as described in several of the posts I linked to.
