Let's Encrypt validation status 400 unable to update challenge

Hello, I can’t get LE to work in some web domains

I have already searched through the forum.

Full error: “Error: Let’s Encrypt validation status 400. Details: Unable to update challenge :: authorization must be pending”

  • The server is used only for web. No local DNS configured.
  • The dns records point correctly to the server IP for both domain.com and www.domain.com - checked via nslookup
  • No IPv6 configuration at all.
  • The server shows correctly the website (wordpress)
  • I have retried and then waited for 12 hours and tried again…

Server status before trying:
image

Then I try this:
image

And I get this:
image

The configuration has changed to this:
image

If I try to save I get the same error.

Any ideas?

try writing in the console:

 v-add-letsencrypt-domain "user" "domain"

replacing with you date “user” and “domain”

I have been getting the same error message for several days now, which does not refer to any specific subdomain, but whenever this has happened to me it has always been related to hestiahostname.domain.tld. For some unknown reason I always have to renew it manually.

I have now disabled the “Enable automatic HTTPS redirection” option on the hestiahostname.domain.tld web subdomain to see if the cron works tonight.

Translated with www.DeepL.com/Translator (free version)

#########

Llevo varios días recibiendo un correo con el mismo mensaje de error, en el que no se hace referencia a ningún subdominio en concreto, pero siempre que me ha ocurrido esto estaba relacionado con hestiahostname.domain.tld. Por alguna razón que desconozco siempre tengo que renovarlo manualmente.

Ahora he desactivado la opción " Habilitar la redirección automática de HTTP a HTTPS" en el subdominio web hestiahostname.domain.tld para comprobar si funciona el cron esta noche.

Pleas check /var/log/hestia/LE-xxxxxx.xxxxx.xxxxx.log

And check the errors why it is not working

Common issues:

  1. Error in a other template for nginx ( run nginx -t )
  2. Proxy is disabled → Enable proxy and try again
  3. CF / Or other Proxies

To check the reason:

cat LE-jaap-mail.xxxxx.nl-20210422-003139.log
Go to step 3:
“challenges”: [
{
“type”: “http-01”,
“status”: “pending”,
“url”: “https://acme-v02.api.letsencrypt.org/acme/chall-v3/xxxxxx/UniqueID”,
“token”: “UniqueID”
},

Follow https://acme-v02.api.letsencrypt.org/acme/chall-v3/xxxxxx/UniqueID in your browser. You are able to see what IP it has been using

1 Like

Hey José, thanks for being informative in your question! good work here :wink:

this is the most likely one, if there is a problem in one of the configs nginx will refuse to reload/restart and therefore the LE challenge cannot be set. so try first to reload nginx manually to see if something pops up.

maybe also check, that you do not have an orphaned entry in the alias field for that domain (I regularly forget about, if I used some staging domain there before…) and verify that the domains are pingable to the correct IP from another server.

other than that I also can only recommend to try running the command from cli and look at the logfiles to get more infos :wink:

1 Like

Thank you @azmandios azmandios.

The output of the hestia script is the same:

Error: Let’s Encrypt validation status 400. Details: Unable to update challenge :: authorization must be pending
Error: Let’s Encrypt SSL creation failed

Thank you @eris
Checked /var/log/hestia/LE-xxxxxx.xxxxx.xxxxx.log and followed the link:
image
The correct server is answering with a 403 error

Thank you @eris and @falzo
nginx -t
nginx: [emerg] open() “/etc/nginx/conf.d/domains/different-domain.com.conf” failed (2: No such file or directory) in /etc/nginx/nginx.conf:149
nginx: configuration file /etc/nginx/nginx.conf test failed

A different domain is failing.

service nginx restart
root@w05:/var/log/hestia# service nginx restart
Job for nginx.service failed because the control process exited with error code.
See “systemctl status nginx.service” and “journalctl -xe” for details.

I will fix that domain and come back to you. This looks promising.

1 Like

That was it.

A deleted user that left an nginx.conf file behind, in particular:
/etc/nginx/conf.d/domains/deleted-domain.com.conf

I just removed the file an restarted. Everything worked fine.

@eris Maybe we could inspect the delete user script to double check if it leaves files behind and output the result of nginx -t in the panel so that we know that there is something wrong with that.

1 Like

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