[SOLVED] The client lacks sufficient authorization :: The key authorization file from the server did not match this challenge


#1

My domain is: stefanmarcin.sk

I ran this command: /root/certbot-auto --apache --staging

It produced this output: Failed authorization procedure. www.stefanmarcin.sk (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 [U7Z05MbBan_sQRbagOsMUOrbrefGfGsWiYZqTbXdz_c.Mxd6puZz877ZrQ7u9cPPc2amincbkMvNFjbgIj9OlQU] != [U7Z05MbBan_sQRbagOsMUOrbrefGfGsWiYZqTbXdz_c.JQoYFoTtPDe2MIr4xFKqpRpt0eKti-HMnJ0BIl9eOjE]

My web server is (include version): Apache/2.2.15

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

My hosting provider, if applicable, is: my own home server

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

Guys, let me describe my problem and my setup:
1 Physical server with Centos 6.10
One virtual apache host - stefanmarcin.sk
No other virtual hosts or main hosts.
I want to apply LE only on that host

Also Document root is default - ,/var/www/html/"
Virtual hosts document root is - ,/home/sites/stefanmarcin"

Acme challenge produces the same error - unauthorized.
What else should I do ?

Thanks.


XSS via ACME implementations
#2

Hi @marhyno

looks like your client uses two different accounts. If you use http-01 - challenge, the content of the file has to contain

  • the token (same as the filename)
  • a dot .
  • a hash value created from your account key.

The error:

U7Z05MbBan_sQRbagOsMUOrbrefGfGsWiYZqTbXdz_c.Mxd6puZz877ZrQ7u9cPPc2amincbkMvNFjbgIj9OlQU
U7Z05MbBan_sQRbagOsMUOrbrefGfGsWiYZqTbXdz_c.JQoYFoTtPDe2MIr4xFKqpRpt0eKti-HMnJ0BIl9eOjE

One is wanted, the other is found. So the token is correct, the dot is correct. But your client sends the wrong hash value (from another account key).

So check your directories. Perhaps there are two accounts.


#3

Please check edited post. I mentioned virtual host has different root directory, could this be the problem ?


#4

This isn’t the problem. Every challenge has an unique token, that’s the filename and the first part of the content.

If the directory would be wrong, Letsencrypt wouldn’t find the correct filename.


#5

What should I check in my directiories ? I dont really understand that part with different accounts.
I am firing certbot with root privileges, and folders are assigned to nobody:nobody with 777 flags (for testing as I ran out of ideas what it could be)
Also - I ran the server behind NAT and I am using port forwarding, so my local address is 192.168.0.100. Just to be informed about my environment.


#6

I don’t understand how it’s possible to create the order with one account and the content of the validation file with another account. But I use my own-written Letsencrypt - client. So I know the format of the file content - token, dot and the hash value.

The first part of your content is correct, only the second part is wrong.


#7

Did you try without --staging?

Could you post the log file from /var/log/letsencrypt?


#8

Yes I used also without --staging
And output from /var/log/letsencrypt below:
certpreparelog.txt (18.7 KB)


#9

There is a certbot-created rewrite rule:

RewriteRule ^/\.well-known/acme-challenge/([A-Za-z0-9-_=]+)$ /var/lib/letsencrypt/http_challenges/$1 [L]

Are there files in /var/lib/letsencrypt/http_challenges/

What happens if you remove all files there? Then test it again.

It’s not a direct solution, but perhaps it may work.

There is another redirect rule from www to non-www. But I don’t know if this is important.


#10

No files have been in that directory and even when I deleted the parent folder, nothing happened, still the same error.
Thinking about /etc/hosts - there must be something specific ?
Also, wordpress is installed, maybe this could be issue ?


#11

@bmw, do you have any ideas about this?


#12

There is an older thread with the same problem:

The key authorization file from the server did not match this challenge [7aniy-jiMmzp5Qi7TD9TD2O7Fi7JXzVzt33_8yzgwyA.K50uFwf8ZXDR6ymNZ8Xjujxw9i3YOPCuL05RBECjTCU] != [7aniy-jiMmzp5Qi7TD9TD2O7Fi7JXzVzt33_8yzgwyA.-f_daEYxVOFls4aupfol2f4PA8ikqBUw-4tU6dotcK8]

But @sahsanu said, that the ipv6 is misconfigured. And removing the ipv6 was the solution.

Then checked

https://letsdebug.net/stefanmarcin.sk/4628?debug=y

[Address Type=IPv4,Server=Apache/2.2.15 (CentOS),HTTP Status=404] vs [Address Type=IPv6,Server=nginx,HTTP Status=200]

ipv6 sends http 200, ipv4 sends 404, this is bad.

So it looks like there are ipv6 - nginx - server which sends the wrong content.

Do you have a nginx and an apache? One used with another Letsencrypt-account?


#13

Thanks @JuergenAuer, now I’m sorry that I forgot to check letsdebug!


#14

Thanks for the effor Juergen, unfortunately I have no nginx running only Apache.

These are services running:

auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
avahi-daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off
blk-availability 0:off 1:on 2:on 3:on 4:on 5:on 6:off
cgconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off
cgred 0:off 1:off 2:off 3:off 4:off 5:off 6:off
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off
dhcpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
dhcpd6 0:off 1:off 2:off 3:off 4:off 5:off 6:off
dhcrelay 0:off 1:off 2:off 3:off 4:off 5:off 6:off
dhcrelay6 0:off 1:off 2:off 3:off 4:off 5:off 6:off
htcacheclean 0:off 1:off 2:off 3:off 4:off 5:off 6:off
httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off
lm_sensors 0:off 1:off 2:on 3:on 4:on 5:on 6:off
mdmonitor 0:off 1:off 2:on 3:on 4:on 5:on 6:off
messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off
minidlna 0:off 1:off 2:on 3:on 4:on 5:on 6:off
mysql 0:off 1:off 2:on 3:on 4:on 5:on 6:off
netconsole 0:off 1:off 2:off 3:off 4:off 5:off 6:off
netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
nmb 0:off 1:off 2:on 3:on 4:on 5:on 6:off
ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
ntpdate 0:off 1:off 2:off 3:off 4:off 5:off 6:off
openvpn 0:off 1:off 2:on 3:on 4:on 5:on 6:off
portreserve 0:off 1:off 2:on 3:on 4:on 5:on 6:off
rdisc 0:off 1:off 2:off 3:off 4:off 5:off 6:off
restorecond 0:off 1:off 2:off 3:off 4:off 5:off 6:off
rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
saslauthd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
smb 0:off 1:off 2:on 3:on 4:on 5:on 6:off
snmpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
snmptrapd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
tcsd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off
vsftpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
winbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off
xinetd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Services Listening:

Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 0 9325 1097/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 10104 1420/sendmail
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 0 10275 1486/smbd
tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 0 129134 15466/minidlnad
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 0 10277 1486/smbd
tcp 0 0 0.0.0.0:16 0.0.0.0:* LISTEN 0 9516 1191/sshd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 0 9611 1227/vsftpd
tcp 0 0 :::631 :::* LISTEN 0 9326 1097/cupsd
tcp 0 0 :::443 :::* LISTEN 0 239203 26826/httpd
tcp 0 0 :::445 :::* LISTEN 0 10270 1486/smbd
tcp 0 0 :::6566 :::* LISTEN 0 9605 1202/xinetd
tcp 0 0 :::3306 :::* LISTEN 27 10009 1329/mysqld
tcp 0 0 :::139 :::* LISTEN 0 10273 1486/smbd
tcp 0 0 :::80 :::* LISTEN 0 239199 26826/httpd
tcp 0 0 :::16 :::* LISTEN 0 9518 1191/sshd
udp 0 0 0.0.0.0:67 0.0.0.0:* 0 10053 1399/dhcpd
udp 0 0 0.0.0.0:59103 0.0.0.0:* 70 9215 1051/avahi-daemon
udp 0 0 0.0.0.0:5353 0.0.0.0:* 70 9214 1051/avahi-daemon
udp 0 0 0.0.0.0:1900 0.0.0.0:* 0 129133 15466/minidlnad
udp 0 0 0.0.0.0:631 0.0.0.0:* 0 9329 1097/cupsd
udp 0 0 10.8.0.1:123 0.0.0.0:* 0 9644 1213/ntpd
udp 0 0 192.168.0.100:123 0.0.0.0:* 0 9643 1213/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 0 9642 1213/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 0 9635 1213/ntpd
udp 0 0 192.168.0.255:137 0.0.0.0:* 0 10213 1467/nmbd
udp 0 0 192.168.0.100:137 0.0.0.0:* 0 10212 1467/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 0 10209 1467/nmbd
udp 0 0 192.168.0.255:138 0.0.0.0:* 0 10215 1467/nmbd
udp 0 0 192.168.0.100:138 0.0.0.0:* 0 10214 1467/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 0 10210 1467/nmbd
udp 0 0 192.168.0.100:56872 0.0.0.0:* 0 129135 15466/minidlnad
udp 0 0 0.0.0.0:1194 0.0.0.0:* 0 9282 1069/openvpn
udp 0 0 fe80::224:e8ff:fe2d:2a65:123 :::* 0 9646 1213/ntpd
udp 0 0 ::1:123 :::* 0 9645 1213/ntpd
udp 0 0 :::123 :::* 0 9636 1213/ntpd

NAT on my home router is enable only for 443 and 80


#15

There is a nginx. Remove the ipv6 - entry in your nameserver menu


#16

Thanks, OK I deleted IPv6 records from my NameServer provider. I will inform you if something change.


#17

Use https://letsdebug.net/stefanmarcin.sk/4632 to check this. There you should see a green OK.

Then you can order a new certificate.


#18

YES ! Finally ! Removing IPv6 from my DNS records on my providers nameserver control panel, issuing new certificates and installing Really Simple SSL plugin did the trick.

Love you guys, thanks a lot.


#19

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