Although, actually, having a closer look at your logs, I note the "detail":
No account exists with the provided key
That might suggest that at some point along the line, Dehydrated thinks that it successfully registered a Let's Encrypt account (as part of the process), but for some reason that account isn't actually valid.
If that's the case, unfortunately, I'm not completely sure. But perhaps you could try moving the Dehydrated data directory out? And starting again. E.g. try this:
mv /var/lib/dehydrated /var/lib/dehydrated.bak
Then try again.
Also, while you are testing it's probably worth noting that to avoid risk of getting rate limited (or at least confirm that it's all working otherwise and isn't a rate limit issue) then it's worth try using the Let's Encrypt staging environment. That won't give you a legitimate certificate, but it will allow you to test your config. You'll find notes about using the staging env with Dehyrated here.
As something of an aside, since the update to a newer version of Dehydrated, another new issue has been occurring for some users (only those with multiple domains, so this may well apply to you). There has been a possible workaround reported but it's untested by us so I can't confirm it. I did start working on a possible fix, but it's a bit dirty and I suspect may well just kick the can down the road a bit. I had some extensive discussions with one of our developers yesterday (who contributed some code to our initial integration, although wasn't responsible for the whole setup; much of that was me). He did start having a look at it and was able to reliably reproduce the issue (which is always a good start to ensuring that a fix is working). He is looking into a much better approach that what I was intending, but haven't heard anything back yet, so not sure where that's up to. Regardless, I suspect that there likely won't be anything solid on that until next week at the absolute earliest.
A couple more things to note:
Firstly, re your comment:
I am moving to setup another server for testing purpose using wordpress since Lamp appears to use Nginx.
Not sure what lead you to that conclusion, but our LAMP appliance (as well as WordPress and about 70% of the library) use Apache to provide the webserving (and shouldn't even have Nginx installed). A few appliances that include software which is essentially self hosting, use Nginx as a front end reverse proxy. And a few other appliances that don't primarily use HTTP, have super simple static html pages (i.e. not PHP apps) served by Nginx (or LigHTTPd). I'm almost certain that currently, the only appliance that uses Nginx to serve PHP is our specific Nginx appliance.
So either the appliance has been mislabelled (unlikely I'd hope - but possible I guess), something else has occurred that I'm unaware of, or you are possibly confused?!
Either way, I'd be really interested to understand what lead you to thinking that LAMP includes Nginx.
Final thing is that if you need Let's Encrypt up and running ASAP and continue to have issues, then it might be worth considering an alternate approach. As you've likely gathered by now, we leverage Dehydrated, so you could use that independently of our setup (i.e. without our wrapper script and with your own config file and hook script). Or alternatively, go with a completely alternate client (e.g. the "official" Let's Encrypt client; "certbot" - it's in the Debian repos and there is an Apache integration also packaged - although I haven't tested it).
FWIW our setup uses a separate mini-server to serve the challenges so the same client and config will work with any of our appliances (or at least that's the intention and how it was working up until a few weeks ago).
I haven't had any experience with anything other than our default setup, but please feel free to ask if you have any questions or issues as I do have intimate knowledge of TurnKey, plus pretty good general knowledge of Debian and Linux more broadly.
Only guessing, but perhaps you've hit the rate limit?
I've just done a quick bit of googling and from a response to an issue noted on Dehydrated's issue tracker (see the second paragraph) and a thread on the Let's Encrypt support forums I suspect that the 400 error is because you've hit the Let's Encrypt rate limit.
Although, actually, having a closer look at your logs, I note the "detail":
That might suggest that at some point along the line, Dehydrated thinks that it successfully registered a Let's Encrypt account (as part of the process), but for some reason that account isn't actually valid.
If that's the case, unfortunately, I'm not completely sure. But perhaps you could try moving the Dehydrated data directory out? And starting again. E.g. try this:
Then try again.
Also, while you are testing it's probably worth noting that to avoid risk of getting rate limited (or at least confirm that it's all working otherwise and isn't a rate limit issue) then it's worth try using the Let's Encrypt staging environment. That won't give you a legitimate certificate, but it will allow you to test your config. You'll find notes about using the staging env with Dehyrated here.
As something of an aside, since the update to a newer version of Dehydrated, another new issue has been occurring for some users (only those with multiple domains, so this may well apply to you). There has been a possible workaround reported but it's untested by us so I can't confirm it. I did start working on a possible fix, but it's a bit dirty and I suspect may well just kick the can down the road a bit. I had some extensive discussions with one of our developers yesterday (who contributed some code to our initial integration, although wasn't responsible for the whole setup; much of that was me). He did start having a look at it and was able to reliably reproduce the issue (which is always a good start to ensuring that a fix is working). He is looking into a much better approach that what I was intending, but haven't heard anything back yet, so not sure where that's up to. Regardless, I suspect that there likely won't be anything solid on that until next week at the absolute earliest.
A couple more things to note:
Firstly, re your comment:
Not sure what lead you to that conclusion, but our LAMP appliance (as well as WordPress and about 70% of the library) use Apache to provide the webserving (and shouldn't even have Nginx installed). A few appliances that include software which is essentially self hosting, use Nginx as a front end reverse proxy. And a few other appliances that don't primarily use HTTP, have super simple static html pages (i.e. not PHP apps) served by Nginx (or LigHTTPd). I'm almost certain that currently, the only appliance that uses Nginx to serve PHP is our specific Nginx appliance.
So either the appliance has been mislabelled (unlikely I'd hope - but possible I guess), something else has occurred that I'm unaware of, or you are possibly confused?!
Either way, I'd be really interested to understand what lead you to thinking that LAMP includes Nginx.
Final thing is that if you need Let's Encrypt up and running ASAP and continue to have issues, then it might be worth considering an alternate approach. As you've likely gathered by now, we leverage Dehydrated, so you could use that independently of our setup (i.e. without our wrapper script and with your own config file and hook script). Or alternatively, go with a completely alternate client (e.g. the "official" Let's Encrypt client; "certbot" - it's in the Debian repos and there is an Apache integration also packaged - although I haven't tested it).
FWIW our setup uses a separate mini-server to serve the challenges so the same client and config will work with any of our appliances (or at least that's the intention and how it was working up until a few weeks ago).
I haven't had any experience with anything other than our default setup, but please feel free to ask if you have any questions or issues as I do have intimate knowledge of TurnKey, plus pretty good general knowledge of Debian and Linux more broadly.