Letsencrypt Challenge Failed for this domain

dalbring · January 11, 2023, 6:58pm

Little background: Installed nethserver using a registered FQDN, then selected an account provider in the cockpit (OpenLDAP) and created a couple users, then created Letsencrypt certificates. Was able to access the server no problem remotely in browsers. This was basically a test setup to see if I liked nethserver.

I registered a new domain for our business, so I had to change the FQDN on my nethserver. In order to change the FQDN, I had to change (unbind) the account provider (basically uninstalls OpenLDAP), which looked as if it deleted the users, and then it allowed me to do change the FQDN in the cockpit dashboard. I was able to again go through the account provider configuration, which reinstalled OpenLDAP, which then automatically restored the previous users that I assumed were deleted from the server. I thought, “Cool”.

However, now when I go to generate a new Letsencrypt certificate, it spits back that the challenge failed for this domain. I’ve included the Letsencrypt.log below. I know my webroot is accessible from port 80 as I can access my nextcloud files with the users created as mentioned above. Any ideas when looking at the log below? Perhaps something’s corrupted when going through the steps mentioned above? Maybe I need to delete some files associated with the previous Letsencrypt certificates in order to generate new ones? Thanks for any insight you can offer.

Domain: rennco.cloud
Type:   unauthorized
Detail: 99.32.54.27: Invalid response from http://rennco.cloud/.well-known/acme-challenge/V4GlXouMzTSheoIQoBV5He0ukdMW0CYTtnyzNtR3abE: 403

Domain: www.rennco.cloud
Type:   unauthorized
Detail: 2a00:1450:400e:810::2013: Invalid response from http://www.rennco.cloud/.well-known/acme-challenge/Sp-FsTC8m7CuVRiI7yA66FLQU_11BgXz5PRLS3lBtJA: 404

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.
2023-01-11 12:21:05,693:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 91, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, best_effort)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 180, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
AuthorizationError: Some challenges have failed.

2023-01-11 12:21:05,693:DEBUG:certbot._internal.error_handler:Calling registered functions
2023-01-11 12:21:05,693:INFO:certbot._internal.auth_handler:Cleaning up challenges
2023-01-11 12:21:05,694:DEBUG:certbot._internal.plugins.webroot:Removing /var/www/html/.well-known/acme-challenge/ny6jc24o714Oq3nTtZwZeObq2ig8DtToQLUxDLw_f4M
2023-01-11 12:21:05,694:DEBUG:certbot._internal.plugins.webroot:Removing /var/www/html/.well-known/acme-challenge/V4GlXouMzTSheoIQoBV5He0ukdMW0CYTtnyzNtR3abE
2023-01-11 12:21:05,694:DEBUG:certbot._internal.plugins.webroot:Removing /var/www/html/.well-known/acme-challenge/Sp-FsTC8m7CuVRiI7yA66FLQU_11BgXz5PRLS3lBtJA
2023-01-11 12:21:05,695:DEBUG:certbot._internal.plugins.webroot:All challenges cleaned up
2023-01-11 12:21:05,695:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 9, in <module>
    load_entry_point('certbot==1.11.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python2.7/site-packages/certbot/main.py", line 15, in main
    return internal_main.main(cli_args)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/main.py", line 1421, in main
    return config.func(config, plugins)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/main.py", line 1294, in certonly
    lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/main.py", line 135, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/client.py", line 441, in obtain_and_enroll_certificate
    cert, chain, key, _ = self.obtain_certificate(domains)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/client.py", line 374, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/client.py", line 421, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 91, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, best_effort)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 180, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
AuthorizationError: Some challenges have failed.
2023-01-11 12:21:05,696:ERROR:certbot._internal.log:Some challenges have failed.

pike · January 11, 2023, 7:09pm

The public DNS already knows the correlation between “new domain” and pubblic address?
Don’t forget that FDQN is host.domain.ext, so maybe “rennco.cloud” might not be suitable for LetsEncrypt standards.

danb35 · January 11, 2023, 7:11pm

A base domain is perfectly acceptable for a Let’s Encrypt cert.

pike · January 11, 2023, 7:13pm

Thanks for the correction, @danb35

dalbring · January 11, 2023, 7:15pm

I’ve included www.rennco.cloud, www.rennco.cloud, and portal.rennco.cloud in the FQDN list for the Letsencrypt certificate generation. When changing the FQDN in my nethserver, it wouldn’t let me use just rennco.cloud. I had to make it portal.rennco.cloud. But in my google domain, I have an A record pointing to the IP address for rennco.cloud, plus a CNAME record for portal.rennco.cloud (and www). This was done a few days ago, so I would think that would be adequate time for their DNS servers to adjust.

michelandre · January 11, 2023, 7:24pm

Hi @dalbring

For the FQDN domain name, you have to also give the server name i.e. name-of-server.rennco.cloud.

Also add a CNAME for name-of-server.rennco.cloud pointing at @.

Good luck,

Michel-André

EDIT:
You need to add an ALIAS in the Server-Manager for portal.rennco.cloud pointing at you server LOCAL IP and just to make sure, add another ALIAS for www.rennco.cloud also pointing at you local server IP address.
That way your server will know portal.rennco.cloud and www.rennco.cloud and will be able to respond to the challenge.
EDIT:
You also need an ALIAS for rennco.cloud pointing at your LOCAL IP.

danb35 · January 11, 2023, 7:24pm

The CNAME for www, and for portal, points to ghs.googlehosted.com. rennco.cloud is an A record pointing to 99.32.54.27.

dalbring · January 11, 2023, 7:36pm

I’ve done that on all accounts.

danb35 · January 11, 2023, 7:37pm

If a hostname doesn’t belong to your Neth server, you won’t be able to get a cert for that hostname.

pike · January 11, 2023, 7:38pm

… two times www.rennco.cloud?

dalbring · January 11, 2023, 7:48pm

I’m sorry, FQDNs for Letsencrypt generation were rennco.cloud, www.rennco.cloud, and portal.rennco.cloud. I’ve tried just using rennco.cloud to generate the certificate, and I’ve also tried to use just portal.rennco.cloud. Both create the same challenge failed error.

BTW, I get an error in the dashboard if I try to add an alias to the FQDN. portal.rennco.cloud is my nethserver’s FQDN I created, but my registered domain name with google is just rennco.cloud. As I’ve said, there are CNAME records for portal and www in my google DNS records. There is also an A record pointing rennco.cloud to 99.32.54.27.

danb35 · January 11, 2023, 7:52pm

Sure–but they don’t point to your neth server. That means you won’t be able to get certs on your neth server for those FQDNs.

michelandre · January 11, 2023, 8:05pm

In SERVER MANAGER
FQDN =>
name-of-server.rennco.cloud

ALIASES =>
rennco.cloud
portal.rennco.cloud
www.rennco.cloud
=> all ALIAS pointing to your LOCAL IP address

DNS records at your registrar:
A rennco.cloud 99.32.54.27
CNAME name-of-server.rennco.cloud @
CNAME portal.rennco.cloud @
CNAME www.rennco.cloud @

For Let’s Encrypt domains =>

rennco.cloud
portal.rennco.cloud
www.rennco.cloud
name-of-server.rennco.cloud

Michel-André

danb35 · January 11, 2023, 8:10pm

Just to be clear, this is a problem. So long as these CNAME entries are in place, you’ll be unable to get certs for the www. and the portal. hostnames. However, those CNAME entries suggest Google is hosting these sites, and if that’s what you intend to be the case, then there’s no reason that you need certs for them anyway.

Do you intend that portal. and www. be hosted by Google? If not, you need to fix your DNS records.

michelandre · January 11, 2023, 8:23pm

Whois for: 99.32.54.27

NetRange: 99.10.64.0 - 99.75.191.255

OrgName: AT&T Corp.
OrgId: AC-3280
Address: 7277 164th Ave NE
Address: Attn: IP Management
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US
RegDate: 2018-03-05
Updated: 2021-06-26

Michel-André

pike · January 11, 2023, 8:38pm

Let’sencrypt fail to challenge. Because public DNS currently is not correctly configured.
So… working as intended?

dalbring · January 12, 2023, 1:04am

I figured it out! Thank you all for all the advice. I love community forums!

I am using google as my domain host. I left my google domain’s (i.e. rennco.cloud) dns records as is, meaning the A record points ‘rennco.cloud’ to my public IP; and the CNAME records add subdomain names ‘portal’ and ‘www’ to my domain name, but then I used rennco.cloud in the data field for the CNAME records. I also left my nethserver’s name as portal.rennco.cloud in the dashboard, with no aliases.

After I did this, I entered my domain name rennco.cloud as the FQDN for letsencrypt and tried to generate the certificate. It took a while before it failed on the challenge, so I reviewed the letsencrypt log and noticed that along with invalid responses from var/www/html/.well-known/acme-challenge, there was also ‘type: unauthorized’ under ‘domain: rennco.cloud’. A little googling pointed me to a redirect issue.

I hadn’t mentioned it earlier because I didn’t think for a minute that it could be an issue (and I swear I removed it once anyway), but I had been forcing a redirect in my webroot using the .htaccess file, which was redirecting traffic to my nextcloud site whenever you enter the domain name without the nextcloud folder included in the browser address. I renamed the htaccess file to take it out of the picture for now and letsencrypt generated the certificate. I then renamed it to .htaccess to allow the redirect.

michelandre · January 12, 2023, 1:53am

Hi @dalbring

In your situation, that is not the proper way to redirect as you will need to rename the .htaccess every 60 days when renewing the certificate.

Try: https://www.rennco.cloud/ and check the result…

Your problem is not solved…

Michel-André

dalbring · January 12, 2023, 4:26am

Good catch, Michel. Thank you. I deleted the certificate and added all versions of what I consider acceptable FQDN’s for our company to the new letsencrypt certificate. Now, when the cert renews, it will still include them. The htaccess script is intended to redirect all of the acceptable browser entries to the nextcloud site, which is the sole purpose of this server in our office, i.e., using nextcloud for a file server to exchange files with customers.

Of course now I’m realizing the redirect will be an issue every time Letsencrypt goes to renew since nethserver puts the check system in the web root. I’ll have to do some more research.

michelandre · January 12, 2023, 3:08pm

Hi @dalbring

For redirection, instead of using .htaccess have a look at the Server Manager module Reverse Proxy.

You can also try to add an Apache .conf file in the directory /etc/httpd/conf.d.

By the way, where is your nexcloud located?

Michel-André