Because you could view the content of the HTTP Domain Control Validation file that eliminates the htaccess file or mod_security firewall as the problem.
That means the 16384 byte response body likely is a 404 page not found error.
The most likely reason that would happen would be because ownership or file permissions were preventing AutoSSL from writing the validation file.
Another user with a similar problem of HTTP Domain Control Validation failing (but with LetsEncrypt) discovered their problem was caused by incorrect ownership or file permissions on the /.well-known/ and or /acme-challenge/ directories.
That user fixed the problem by deleting the /.well-known/ directory and having AutoSSL automatically recreate it next time they tried to run AutoSSL.
The thread is here. SOLVED - AutoSSL can't verify/install certs
first of all thank you for taking the time in helping me in regards to this issue. Let me outline once again all the steps followed:
1. Deleted the sub-domain entirely (also the physical folder) and recreated it from scratch with the migrated site.
2. Deleted the sub-domain entirely (also the physical folder) and recreated it from scratch with a default wordpress site
3. Enabled "Use a Global DCV Passthrough"
4. Disabled the "Use a Global DCV Passthrough" and also UNCHECKED the Enable legacy 5G Firewall Protection on worpress (also disable 6G just in case)
5. Having disabled the "Use a Global DCV Passthrough" i removed User-Agent COMODO from the keep_out in .htaccess
6. Momentarily changed permissions to 777 on the .well-known folders
7. Also mixed and matched any of the above steps. To be honest i cannot remember the combinations any more...
With "Use a Global DCV Passthrough" disabled i get:
...Size of response body exceeds the maximum allowed of 16384.
With "Use a Global DCV Passthrough" enabled i get:
...the web server responded with the following error: 403 (Forbidden).
I'd imagine that although the .well-known folders are recreated every time, the .txt is not. Unless by default it is instantly created and deleted.
The only thing left is to delete the account entirely and do it from scratch. On the other hand I want to make sure that i don't need to do that every time something like that happens. There are going to be occasions that such workaround won't be an available option and i'm already having second thoughts in regards to migrating other sites in this server before i get this resolved.
Still i cannot recreate the same error on any other account. Other thoughts that i had are that domain.com is hosted elsewhere and of course the auto-ssl fails. Does that affect the process auto-ssl of subdomain.domain.com in anyway? I cannot really understand how...