My domain is: mediconfort.com
I ran this command:
I have a pod on kubernetes that run this command "certbot certonly --webroot --webroot-path /usr/share/nginx/html -d mediconfort.com"
It produced this output:
'Error accepting authorization: acme: authorization error for mediconfort.com: 403 urn:ietf:params:acme:error:unauthorized: The key authorization file from the server did not match this challenge. Expected "dKX8XN5WrdpPrAxELrfcJnkXkUeaUzcS3Q2IS_6cD98.nX2cH20pStJZqsIBA9rt1ll1_2Iy2KPJsqTGEJkHKVI" (got "dKX8XN5WrdpPrAxELrfcJnkXkUeaUzcS3Q2IS_6cD98.4E3VCTFsySjUrqnCg0ooULx-3kbdPBygi0aWkvg5Gd8"
Notice that if I do a "curl -i -v http://mediconfort.com/.well-known/acme-challenge/dKX8XN5WrdpPrAxELrfcJnkXkUeaUzcS3Q2IS_6cD98".
I receive the correct challenge dKX8XN5WrdpPrAxELrfcJnkXkUeaUzcS3Q2IS_6cD98.nX2cH20pStJZqsIBA9rt1ll1_2Iy2KPJsqTGEJkHKVI
although the ACME server states that it received dKX8XN5WrdpPrAxELrfcJnkXkUeaUzcS3Q2IS_6cD98.4E3VCTFsySjUrqnCg0ooULx-3kbdPBygi0aWkvg5Gd8
that's the whole output and is always the same with multiple curl's...
root@archlinux: certificates:#curl -i -v http://mediconfort.com/.well-known/acme-challenge/dKX8XN5WrdpPrAxELrfcJnkXkUeaUzcS3Q2IS_6cD98; echo
* Host mediconfort.com:80 was resolved.
* IPv6: 2001:41d0:1:1b00:213:186:33:18
* IPv4: 195.154.139.76
* Trying 195.154.139.76:80...
* Connected to mediconfort.com (195.154.139.76) port 80
> GET /.well-known/acme-challenge/dKX8XN5WrdpPrAxELrfcJnkXkUeaUzcS3Q2IS_6cD98 HTTP/1.1
> Host: mediconfort.com
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< date: Wed, 17 Jan 2024 20:14:03 GMT
date: Wed, 17 Jan 2024 20:14:03 GMT
< content-type: text/plain; charset=utf-8
content-type: text/plain; charset=utf-8
< content-length: 87
content-length: 87
< cache-control: no-cache, no-store, must-revalidate
cache-control: no-cache, no-store, must-revalidate
< x-content-type-options: nosniff
x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
x-frame-options: SAMEORIGIN
< referrer-policy: strict-origin
referrer-policy: strict-origin
<
* Connection #0 to host mediconfort.com left intact
dKX8XN5WrdpPrAxELrfcJnkXkUeaUzcS3Q2IS_6cD98.nX2cH20pStJZqsIBA9rt1ll1_2Iy2KPJsqTGEJkHKVI
Notice I am curling a public ip and i do not reside inside a VPN, also my webserver serving the challenge does not use any cache! It's weird that my curl is returning a different challenge than what the "letsencrypt ACME server" is stating... we are both curling the same url http://mediconfort.com/.well-known/acme-challenge/xxxxxxxxxxxx I suppose!
I have tried with several different letsencrypt accounts (having different emails) on different pods (meaning no chance to have multiple accounts running at once inside the pod...), and I always have the same error from the ACME server although my curl returns the correct challenge!
Notice it does work fine with other certs like xxx.mediconfort.com
I have waited several days before each try cause i suspected there was some sort of caching issue somewhere on the ACME server sides (not sure)!
I am getting a bit out of ideas 
My web server is (include version): .NET 8.0
The operating system my web server runs on is (include version): Linux
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know): no
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): certbot 2.7.4
!