User account ID doesn't match account ID in authorization

Hi!.

I try to get a new certificate for the domain, but I get the following error:
Invalid response from https://acme-v02.api.letsencrypt.org/acme/challenge/ApBI0gD3x9st2KZHAro8LSka3SpJmhaJI-TOIhXB4FY/13043443231.
Details:
Type: urn: ietf: params: acme: error: unauthorized
Status: 403
Detail: User account ID does not match account ID in authorization

Being a new certificate for the domain, I do not understand that IDs do not match …

I have checked the path where you should create the validation file, and it is accessible: http://toptoner.es/.well-known/acme-challenge/Njf9fFuK6jVBf-H-hqPlZtaqSDzaIIS63fcufmNGAf8

Is there any way to delete the ID and rebuild another? I really do not understand the error, I do not know what Id’s refers to.

I appreciate any help

Domain: toptoner.es
Use Plesk with the Let Encrypt extension

Are you running Plesk on a system where you have full control? And installed Plesk yourself et c.? Or do you have shared hosting without root access where your provider provided Plesk?

1 Like

I have full control over the server.
The fact is that with other domains within the same server I have no problems, it is only with this domain, so I understand that it is nothing of the Plesk configuration or the extension.

Hi @HuNTy,

This is a pretty strange situation! I second @Osiris's request for more information about your Plesk setup - I think something has gone quite wrong with the ACME client that your system is using.

When I look at the server side logs I can see that the ApBI0gD3x9st2KZHAro8LSka3SpJmhaJI-TOIhXB4FY authorization you mention was created on 27/02/2019 at 11:34:50 UTC by the account ID 52315893. Two seconds later that same account successfully POSTed the authorization's HTTP-01 challenge and the challenge succeeded so the authorization is now valid :tada:

The problems start at 11:35:12 UTC that same day. A different account ID with the same contact address (ID: 52315900) started to try and POST the challenge on that authz. That's broken for two reasons:

  1. The authz is already valid, so there's no challenges that need to be done.
  2. Its the wrong account and doesn't own the authorization so the error you're seeing is returned.

Over the past 3 days I can see there were close to ~8 different ACME account IDs that tried to POST this challenge after it was already valid.

With all that technical information out of the way: I think you should try and contact Plesk support and find out what could be causing your server to get confused like this. It seems like it's creating new ACME accounts over and over but is also remembering authorizations it previously created. Unfortunately I'm not familiar with Plesk to guess at a root cause :frowning: It smells like a bug in the Plesk ACME client.

Hopefully some of the information in this thread will be helpful to Plesk support (or perhaps someone else can guess at the root cause with the server-side information I provided in hand).

1 Like

Hi @HuNTy

you have a curious situation: Ipv4 and ipv6 ( https://check-your-website.server-daten.de/?q=toptoner.es ):

Host T IP-Address is auth. ∑ Queries ∑ Timeout
toptoner.es A 91.146.97.111 yes 2 0
AAAA 2a01:71c0:2:1:111::53 yes
www.toptoner.es C toptoner.es yes 1 0
A 91.146.97.111 yes
AAAA 2a01:71c0:2:1:111::53 yes

but your ipv4 and ipv6 differs:

Domainname Http-Status redirect Sec. G
http://toptoner.es/
91.146.97.111 302 http://www.toptoner.es/ 0.160 D
http://toptoner.es/
2a01:71c0:2:1:111::53 302 http://www.toptoner.es/ 0.140 D
http://www.toptoner.es/
91.146.97.111 503 0.264 S
Service Unavailable
http://www.toptoner.es/
2a01:71c0:2:1:111::53 503 0.317 S
Service Unavailable
https://toptoner.es/
91.146.97.111 302 http://www.toptoner.es/ 1.597 N
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
https://toptoner.es/
2a01:71c0:2:1:111::53 302 http://www.toptoner.es/ 1.957 F
https://www.toptoner.es/
91.146.97.111 302 http://www.toptoner.es/ 1.673 N
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
https://www.toptoner.es/
2a01:71c0:2:1:111::53 302 http://www.toptoner.es/ 1.697 F
http://toptoner.es/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
91.146.97.111 404 0.107 A
Not Found
Visible Content: 404 Not Found nginx
http://toptoner.es/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2a01:71c0:2:1:111::53 404 0.107 A
Not Found
Visible Content: 404 Not Found nginx
http://www.toptoner.es/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
91.146.97.111 404 0.103 A
Not Found
Visible Content: 404 Not Found nginx
http://www.toptoner.es/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2a01:71c0:2:1:111::53 404 0.107 A
Not Found
Visible Content: 404 Not Found nginx

http + ipv4 + ipv6 + www has a Service unavailable - 503, but /.well-known works in all combinations.

And your correct certificate

CN=toptoner.es
	01.03.2019
	30.05.2019
expires in 90 days	toptoner.es, www.toptoner.es - 2 entries

is only used with your two ipv6 connections.

Both ipv4 connections use an expired self signed certificate:

E=info@parallels.com, CN=Parallels Panel, OU=Parallels Panel, O=Parallels, L=Herndon, S=Virginia, C=US
	12.07.2011
	11.07.2012
2424 days expired

So ipv6 is secure, ipv4 not.

There is a header:

X-Powered-By: Loading

Is that another instance?

1 Like

Thanks for the tests.

What you indicate is for some tests that I have done.
The indicated Ips, IPv4 and IPv6 are correct and I had configured an SSL Certificate over IPv6 for some tests.

The strange thing is that on the same server and from Plesk, with other domains I have no problems. That’s why I think it’s not because of the server configuration …

Is there a way to reset everything and be able to redo the certificate request from 0? Or to recover the data the correct authorization to obtain the data of the certificate?

I'm afraid the answer to these questions are Plesk specific and I'm not sure :frowning:

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