The key authorization file from the server did not match this challenge

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: cherberg.de

I ran this command: ./certbot-auto renew

It produced this output:
Plugins selected: Authenticator apache, Installer None

Renewing an existing certificate

Performing the following challenges:

http-01 challenge for cherberg.de

Waiting for verification…

Cleaning up challenges

Attempting to renew cert (cherberg.de) from /etc/letsencrypt/renewal/cherberg.de.conf produced an unexpected error: Failed authorization procedure. cherberg.de (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: The key authorization file from the server did not match this challenge [HTjSal-Fd1-C7v5I8XBszImvF5rVidmsMQ5NsvA-BXg.lsGRooYEb3t2f5-PGJdbLNkdAbUwNckqbqa_D3v-HrE] != [<html><head><title>cherberg.de</title></head><body><center><b>Diese Domain ist unkonfiguriert.</b></center></body></html>]. Skipping.

All renewal attempts failed. The following certs could not be renewed:

/etc/letsencrypt/live/cherberg.de/fullchain.pem (failure)

My web server is (include version): Apache

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

My hosting provider, if applicable, is: private hosting via DDNS

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

IPv4:80 is blocked.
IPv6:80 is allowed but all requests seem to return the same 121 bytes:

<html><head><title>cherberg.de</title></head><body><center><b>Diese Domain ist unkonfiguriert.</b></center></body></html>

Hi @cherberg

there are a lot of things.

First, you have ipv4 and ipv6:

Host T IP-Address is auth. ∑ Queries ∑ Timeout
cherberg.de A 92.201.194.79 yes 1 0
AAAA 2A01:04F8:0190:62F4:0000:0000:0000:0013 yes
www.cherberg.de A 93.129.177.51 yes 1 0
AAAA 2A01:04F8:0190:62F4:0000:0000:0000:0013 yes

Is your webserver configured?

Then:

Diese Domain ist unkonfiguriert.

Looks like the message is only a standard message of the system, generated via ipv6.

And your ipv4 has timeouts:

Domainname Http-Status redirect Sec. G
• http://cherberg.de/
92.201.194.79 -14 10.027 T
Timeout - The operation has timed out
• http://www.cherberg.de/
93.129.177.51 -14 10.027 T
Timeout - The operation has timed out
• https://cherberg.de/
92.201.194.79 302 Access via Synology 8.347 N
Certificate error: RemoteCertificateChainErrors
• https://www.cherberg.de/
93.129.177.51 -14 10.026 T
Timeout - The operation has timed out
• Access via Synology 200 4.280 N
Certificate error: RemoteCertificateChainErrors
• Access via Synology
92.201.194.79 -14 10.026 T
Timeout - The operation has timed out
• Access via Synology
93.129.177.51 -14 10.026 T
Timeout - The operation has timed out

So http-01 - validation wouldn't work.

Also, the IPv6 web server claims to be lighttpd/1.4.28 (released in 2010).

1 Like

Are you sure your Dynamic DNS for your IPv4 address is current/updated?

Based on previous IP addresses for your domain, your site was working and actually advertising Apache httpd, so it’s possible that the domain is just currently pointing to a different IPv4 host entirely.

Dear Pros,

thanx for all your input, however unfortunately I have no idea how to solve the problem. I am not an expert at all. I have setup the system (Nextcloud) following a step by step guide and it used to work fine for the past couple of years, the renewal of the certs also went without any problem.

I am using DynDNS to point the domain “cherberg.de” to my server at home behind my DSL Router (Fritzbox). I have contacted my Domain Provider and they said they cannot find anything wrong.

When entering https://cherberg.de in a browser I am correctly lead to my server so I cannot confirm the assumption that the forwarding is not working.
Calling http://cherberg.de should reroute to https, and when entering http://cherberg.de, I am also connected to https://cherberg.de so this also seems to work.

www.cherberg.de should be unconfigured, the Provider allows to chose between cherberg.de and www.cherberg.de, I am using DynDNS only for cherberg.de

Also when checking the FlexDNS Config Page of my provider (www.do.de) shows the current IP Adress of my DSL Connection. Also when pinging cherberg.de I can see the same correct IP Address. No idea about IPv4 vs IPv6, I am not using this in my Router and there are no options to configure this anywhere in the Config of my provider.

The Error message “Domain ist unkonfiguriert” is somewhat confusing as this is the message that appears when trying to access an unconfigured domain that I have reserved with the same provider. So I am quite lost :frowning:

any idea how to solve this mystery?

Thanx so much for all your help

br Christian

You don't have one ip address. You have three different:

Host T IP-Address is auth. ∑ Queries ∑ Timeout
cherberg.de A 92.201.177.229 yes 1 0
AAAA 2a01:4f8:190:62f4::13 yes
www.cherberg.de A 78.47.59.169 yes 1 0
AAAA 2a01:4f8:190:62f4::13 yes

Every address must answer correct.

But rechecking your domain ( cherberg.de - Make your website better - DNS, redirects, mixed content, certificates ) there are timeouts.

And checking a not existing file in /.well-known/acme-challenge, there is a http status 200 instead of 404.

If you don't configure these other addresses correct, remove these addresses.

Or use dns-01 - validation, then you don't need a correct configured webserver.

Alright I have have deleted and recreated the whole DYN DNS forwarding in the settings page of my provider. I believe this has fixed the issue but now I am getting another error:


Renewing an existing certificate
Performing the following challenges:
http-01 challenge for cherberg.de
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (cherberg.de) from /etc/letsencrypt/renewal/cherberg.de .conf produced an unexpected error: Failed authorization procedure. cherberg.de (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://cherberg.de/.well-known/a cme-challenge/sTWC9MWYJKXaTNLj1pAVrQdNgKNtcI8yirOH3kxsgFM: Error getting validat ion data. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/cherberg.de/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/cherberg.de/fullchain.pem (failure)


1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: cherberg.de
    Type: connection
    Detail: Fetching
    http://cherberg.de/.well-known/acme-challenge/sTWC9MWYJKXaTNLj1pAVrQdNgKNtcI8 yirOH3kxsgFM:
    Error getting validation data

    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.
    pi@raspberrypi:/etc/letsencrypt $ 92.201.177.229


Any further help to get this fixed would be greatly appreciated.

Now you have removed your ipv6.

Your http port 80 doesn’t answer ( https://check-your-website.server-daten.de/?q=cherberg.de ):

Domainname Http-Status redirect Sec. G
• http://cherberg.de/
92.201.177.229 -14 10.027 T
Timeout - The operation has timed out
• http://www.cherberg.de/
78.47.59.169 200 0.047 H
• https://cherberg.de/
92.201.177.229 302 https://cherberg.de/index.php/login 8.537 N
Certificate error: RemoteCertificateChainErrors
• https://www.cherberg.de/
78.47.59.169 -2 1.073 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 78.47.59.169:443
• https://cherberg.de/index.php/login 200 8.037 N
Certificate error: RemoteCertificateChainErrors
• http://cherberg.de/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
92.201.177.229 -14 10.027 T
Timeout - The operation has timed out

Only a timeout is visible.

Checking https://cherberg.de/ there is a Nextcloud login. So it looks like a home server.

Is there a router? Is there a correct port forwarding port 80 extern -> port 80 intern?

https://cherberg.de/ is the adress I have been using for my Nextcloud server hosted at home.

This stands behind a Fritzbox router with port forwarding for port 443 only. There is no and never has been a port forwarding for port 80 since I believe this would be http which I do not want anyways.

Any idea to fix the error I am now getting from the Letsencrypt certbot? I reads like there is a file missing, but I have no idea what and where to look. There is no /.well-known/ folder in my var/www/nextcloud/ folder.

I am still running an older version of nextcloud since during upgrade I had received some weird error complaining about “well-known”. I was never able to solve this and nobody was able to help so I just left it as it was.

If you want to use http-01 validation, such an open port 80 and a port forwarding is required.

Certbot creates a file under /.well-known/acme-challenge, Letsencrypt checks this file to verify that you are the legitimate domain owner.

So if you don't want to open port 80, you have to use dns-01 validation.

I am sorry but I do not know what that means. As mentioned there never has been a port 80 forwarding and I have been using the ./certbot-auto renew command for years now.

Sorry again but I do not know what this means, there is no such folder to be found anywhere with my very limited Linux skills. :frowning:

You may have used tls-sni-01 - validation. That had worked with port 443.

But this is deprecated, support ends now.

So you have to change to another validation method.

Of course it's good that you don't want to make your Nextcloud instance available over HTTP :slight_smile: However, you don't need to do that - it's sufficient to configure your web server to respond to all HTTP requests with a simple redirect to HTTPS - as long as the redirect preserves the URL path, the HTTP-01 challenge should work.

See also: Best Practice - Keep Port 80 Open - Let's Encrypt

Certbot creates the folder automatically in a special location during the renewal process and temporarily configures your webserver to serve /.well-known/acme-challenge/* requests from there; this configuration is reverted once the renewal is complete.

Since I have no idea how to accomplish this I have openend port 80 forwarding in my router and was able to renew the certificate.

THANX ALOT for your help!! :+1::grinning:

One last thing:

Would you be able to help me navigate to this "special location" in a Raspian Linux environment? I would like to try to delete this folder to finally be able to upgrade my Nextcloud installation which as mentioned fails complaiing about the existence of this folder.

2 Likes

Since you're apparently using the apache authenticator plugin, it's unlikely that Nextcloud would complain about the folder that Certbot automatically creates, since it's outside of the area of your filesystem that Nextcloud cares about.

If you previously used the webroot plugin though, it might have left a .well-known folder behind in the web root used by Nextcloud, which Nextcloud might complain about if it does some sort of integrity check before upgrading - which I believe it does. The folder is hidden by default because it begins with a dot, but you can show it (if it exists) by typing:

ls -a /var/www/nextcloud

(or whatever your nextcloud web root directory is).

Yep, now your http port is open, http + /.well-known/acme-challenge is redirected to the https - version.

I don't see a real security problem with such a configuration. A redirect sends no real data. Then follows https.

1 Like

YES, found it and deleted that little critter, creation date was early 2017. :slight_smile:

Thanx everyone for your time and help. This is greatly appreciated!

2 Likes

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