Challenge failed for domain/Error getting validation data

Help
1

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:
www.fleet.org,mail.fleet.org

I ran this command:
certbot-auto

It produced this output:
/opt/eff.org/certbot/venv/lib/python2.7/site-packages/cryptography/hazmat/primitives/constant_time.py:26: CryptographyDeprecationWarning: Support for your Python version is deprecated. The next version of cryptography will remove support. Please upgrade to a 2.7.x release that supports hmac.compare_digest as soon as possible.
utils.PersistentlyDeprecated2018,
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?

1: mail.fleet.org
2: www.fleet.org

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel):
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mail.fleet.org
http-01 challenge for www.fleet.org
Waiting for verification…
Challenge failed for domain mail.fleet.org
Challenge failed for domain www.fleet.org
http-01 challenge for mail.fleet.org
http-01 challenge for www.fleet.org
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

My web server is (include version):
Apache2.4

The operating system my web server runs on is (include version):
Fedora 20

My hosting provider, if applicable, is:
N/A

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):
no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
/opt/eff.org/certbot/venv/lib/python2.7/site-packages/cryptography/hazmat/primitives/constant_time.py:26: CryptographyDeprecationWarning: Support for your Python version is deprecated. The next version of cryptography will remove support. Please upgrade to a 2.7.x release that supports hmac.compare_digest as soon as possible.
utils.PersistentlyDeprecated2018,
certbot 0.34.2

I have been using LetsEncryupt certificates for a couple of years or more. I got a renewal notice in December of last year. I attempted to run certbot-auto, which did an automated upgrade, then produced the errors above. I have been unsuccessful in generating renewed SSL certs since that time. I even today tried to remove all the previous LetsEncrypt-related files and directories in order to “start fresh”. No difference, same error I’ve been getting since December. While I do plan to upgrade the Fedora 20 server to Centos 7 (or perhaps Fedora 30 or Centos 8, depending), I am unable to do so today, but would like to fix the expired cert problem so that my Androids can communicate with the site (especially email).

Can anyone point me to a solution, or further steps to try? Thank you.

2

Neither of your IP addresses (71.216.244.97, 71.216.244.98) respond to connection requests on port 80 or port 443.

Is it possible that Centurylink have blocked your incoming ports? Have you changed your port forwarding? Maybe you added some IP whitelisting?

1 Like
3

I do have IP whitelisting, however 66.133.109.36 is included in that list and the firewall does log successful connections.

Are there other IP addresses which should be allowed to connect to my server from letsencrypt.org (or other sites for some reason)? This used to be sufficient prior to December.

Thank you for the suggestions.

4

Whitelisting Let's Encrypt validation servers won't work.

The IP addresses are not stable, and in the near future, Let's Encrypt will begin using multiple network vantage points to perform validation (they already do for staging/dry-runs).

From FAQ - Let's Encrypt :

What IP addresses does Let’s Encrypt use to validate my web server?
We don’t publish a list of IP addresses we use to validate, because they may change at any time. In the future we may validate from multiple IP addresses at once.

If public access to your webservers isn't something that works for you, then the DNS-01 challenge is the alternative approach you can use.

1 Like
5

Thank you for more suggestions. Unfortunately, that isn’t it. I opened up ports 80 & 443 to the entire IPv4 universe and I don’t even see evidence now that anything is even trying to connect.

What else should I try?

6

Well, the TCP connection is established, but it doesn’t seem to speak HTTP:

https://letsdebug.net/www.fleet.org/42059

Seems to just drop the connection after reading the request.

7

It works on port 443 from a test station I’m using, but doesn’t seem to for port 80. Did you see that result as well? Or was it not speaking HTTP from either port for you?

It looks like I need to fix the port 80 part again (I think I used to redirect it, then later shut it down. Not sure the port 80 config at the moment, so that’s first on my list).

Thanks again!

8

Well, whether or not port 443 works doesn’t really matter, since Let’s Encrypt HTTP-01 validation always begins over port 80.

But it seems like both ports have gone back to not accepting TCP connections once again.

Edit: now they accept, HTTP gives the EOF and HTTPS actually seems to send some data.

9

Thank you very much for taking the time to explain the expectations to me. Since it became obvious that I don’t remember the initial config of that server and it was running on Fedora 20, I opted to rebuild it with Fedora 30 and configured as you explained, and all is good, now.

Thank you again!

1 Like
10

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