Too many failed authorizations recently

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. crt.sh | 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: cyberlight.solutions

I ran this command: sudo certbot --apache

It produced this output: Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?

1: cyberlight.solutions
2: www.cyberlight.solutions

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1,2
Requesting a certificate for cyberlight.solutions and www.cyberlight.solutions

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: cyberlight.solutions
Type: dns
Detail: no valid A records found for cyberlight.solutions; no valid AAAA records found for cyberlight.solutions

Domain: www.cyberlight.solutions
Type: dns
Detail: no valid A records found for www.cyberlight.solutions; no valid AAAA records found for www.cyberlight.solutions

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): self hosted

The operating system my web server runs on is (include version): ubuntu 20.04

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

2

You've pointed your domain to 192.168.1.141, but this is a private IP address.

This is a problem because Let's Encrypt is unable to connect to it (from the external internet) in order to confirm your control of the domain name.

Usually, you will want to point the domain to your public IP address, and then set up port forwarding on that public IP address, on TCP ports 80 and 443 towards 192.168.1.141 in your local network.

3 Likes
3

The error message provided by Boulder is very confusing in this regard.

2 Likes
4

Yeah it kinda sucks. I think it's because Unbound filters out these ranges before they hit Boulder. I'm not sure whether there's anything they can do about it without major changes :man_shrugging: .

2 Likes
5

As far as I can tell, this behaviour is coded in Boulder. See:

There the IP address is checked for being private or not. If not private, then it's added to the results, assuming dnsClient.allowRestrictedAddresses is false. I have not checked, but I think this is the only check for private addresses. Personally, I would rather see any private address added to the list, but returning an error if the list of IP addresses consists only of private addresses and if that's not the case, filter out the private addresses. But I'll leave that to the Boulder devs and/or other persons "speaking" Go :stuck_out_tongue:

Also, luckily @griffin has already opened an issue on Github about this: Improve problem+json message for private IP addresses during HTTP-01 verification · Issue #5647 · letsencrypt/boulder · GitHub :slight_smile:

5 Likes
6

I am 99% sure that it's also configured in Unbound as well, because we had that weird issue recently with Unbound stripping the DNSSEC signature from signed zones which contained private addresses, resulting in SERVFAILs.

4 Likes
7

Could of course be implemented in both indeed, which would make fixing it possibly a lot more difficult?

1 Like
9

Your DNS looks good if your public IP is 31.21.242.27.

But, your NAT routing looks wrong. Port 80 and 443 should use the same IPs. The server IP for port 80 might be wrong you have 191.168.1.141. Did you mean to type 192.168.1.141?

You can test your port 80 setup using Let's Debug. Once that works you should set the port 443 settings to the same IP's as port 80.

2 Likes
10

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