Size of response body exceeds the maximum allowed

[1oann1s]

I have recently installed whm and autossl was working like a charm. I've created another account with a new subdomain and checked the AutoSSL logs after making the request.

First it was returning:
Size of response body exceeds the maximum allowed of 16384

Then going through various posts I ended up deleting the subdomain entirely and recreated it with a typical wordpress installation just in case it was the .htaccess file from migration of the original site. Still another error would appear:
but the web server responded with the following error: 403 (Forbidden)

I even disabled ioncube in case it was messing with the process but without luck. So, after a days work, I come to you for your valuable insights.

 

[cPanelMichael]

Still another error would appear:
but the web server responded with the following error: 403 (Forbidden)

Hello,

Could you let us know the full entries from the "Logs" tab in "WHM >> Manage AutoSSL" for the affected domain name? Also, could you let us know the contents of the .htaccess file in the document root of that domain name?

Thank you.

 

[1oann1s]

Hello,

Could you let us know the full entries from the "Logs" tab in "WHM >> Manage AutoSSL" for the affected domain name? Also, could you let us know the contents of the .htaccess file in the document root of that domain name?

Thank you.

WHM:

The domain “subdomain.example.com” failed domain control validation: The system failed to fetch the <abbr title="Domain Control Validation">DCV</abbr> file at “<a href="http://subdomain.example.com/.well-known/pki-validation/563CB6EB201014130BBFFC9934EBD32E.txt">http://subdomain.example.com/.well-known/pki-validation/563CB6EB201014130BBFFC9934EBD32E.txt</a>” because of an error: The system failed to send an <abbr title="Hypertext Transfer Protocol">HTTP</abbr> “GET” request to “http://subdomain.example.com/.well-known/pki-validation/563CB6EB201014130BBFFC9934EBD32E.txt” because of an error: Size of response body exceeds the maximum allowed of 16384 .

current .htaccess (also used auto-generated one when deleted the subdomain and re-created with a default wordpress installation.


- Removed -

 

[cPanelMichael]

Hello,

Can you enable the "Use a Global DCV Passthrough instead of .htaccess modification (requires EA4)" option under the "Domains" tab in "WHM >> Tweak Settings" and let us know if domain validation attempts continue to fail?

Thank you.

 

[fuzzylogic]

cPanel Michael has offered you a reliable alternative method of SSL validation.

If you want to understand why the current method of domain validation is not working and how to fix it from within WordPress Admin you should read my post about All in One Wordpress Security 5G:[USER AGENTS] section being enabled. You can find it here...
AutoSSL not renewed due to content in .htaccess file

 

[1oann1s]

Hello,

Can you enable the "Use a Global DCV Passthrough instead of .htaccess modification (requires EA4)" option under the "Domains" tab in "WHM >> Tweak Settings" and let us know if domain validation attempts continue to fail?

Thank you.

Michael thank you for your input and prompt reply. Unfortunately now from:
#Size of response body exceeds the maximum allowed of 16384

we changed to:
#but the web server responded with the following error: 403 (Forbidden).

I'm pretty sure that its something that I've tweaked. From what I can remember I enabled mod_rewrite and ioncube. Other than that, i cannot think of something.

 

[1oann1s]

cPanel Michael has offered you a reliable alternative method of SSL validation.

If you want to understand why the current method of domain validation is not working and how to fix it from within WordPress you should read my post about All in One Wordpress Security 5G:[USER AGENTS] section being enabled. You can find it here...
AutoSSL not renewed due to content in .htaccess file

Dear fuzzy, thank you for tying valuable information to this query. Since I went knee deep on this one and is already a production server, I'll make sure that it works first, ask questions (know why) later. But yes, this is the only way forward and i appreciate you taking the time to explain why, as well as to post it here.

 

[1oann1s]

May i also add that i can see the folder structure public_html/subdomain/.well-known/pki-validation but the folder is empty.

 

[fuzzylogic]

I will stop trying to explain and give you a recipe to try.
1). Disable the "Use a Global DCV Passthrough" option under the "Domains" tab in "WHM >> Tweak Settings"
This will change the Domain Control Validation method back to the cPanel default http based validation.
It will create a file in public_html/subdomain/.well-known/pki-validation when you try to install the SSL which comodo will try to read to validate.
2). Log into your WordPress Admin. Go to...
WP Security => Settings => Firewall => 6G Blacklist Firewall Rules => Enable legacy 5G Firewall Protection: (checkbox)
and UNCHECK the Enable legacy 5G Firewall Protection: (checkbox) - This is the source of the problem.
This will remove the blocking code from you .htaccess file.
3). Try to install the SSL onto the subdomain.

 

[1oann1s]

cPanel Michael has offered you a reliable alternative method of SSL validation.

If you want to understand why the current method of domain validation is not working and how to fix it from within WordPress Admin you should read my post about All in One Wordpress Security 5G:[USER AGENTS] section being enabled. You can find it here...
AutoSSL not renewed due to content in .htaccess file

Done that also but to no avail...

 

[1oann1s]

I will stop trying to explain and give you a recipe to try.
1). Disable the "Use a Global DCV Passthrough" option under the "Domains" tab in "WHM >> Tweak Settings"
This will change the Domain Control Validation method back to the cPanel default http based validation.
It will create a file in public_html/subdomain/.well-known/pki-validation when you try to install the SSL which comodo will try to read to validate.
2). Log into your WordPress Admin. Go to...
WP Security => Settings => Firewall => 6G Blacklist Firewall Rules => Enable legacy 5G Firewall Protection: (checkbox)
and UNCHECK the Enable legacy 5G Firewall Protection: (checkbox) - This is the source of the problem.
This will remove the blocking code from you .htaccess file.
3). Try to install the SSL onto the subdomain.

Manually removed comodo from keep_out before, also followed your thorough instructions (thanx) and we are back to:
##Size of response body exceeds the maximum allowed of 16384

 

[fuzzylogic]

OK. That looks like my assumption was wrong. Sorry about that.
I would expect that the 16384 byte response body would be a WordPress error page.
Either 404 or 403.
To test how your server is responding to the Domain Validation request from comodo you could create a test validation file named
C7FBC2039E400C8EF74129EC7DB1842C.txt in the
public_html/subdomain/.well-known/pki-validation/ directory with the content
c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f
comodoca.com
10af9db9tu
then try to access it using a browser on the url
http://subdomain.domain.com/.well-known/pki-validation/C7FBC2039E400C8EF74129EC7DB1842C.txt
Look for error responses or redirects (The address bar being different to http://subdomain.domain.com after page load)
Error responses or redirects will cause the http Domain Validation to fail.

 

[cPanelMichael]

Hello,

Feel free to open a support ticket using the link in my signature if you'd like us to take a closer look.

Thanks!

 

[1oann1s]

OK. That looks like my assumption was wrong. Sorry about that.
I would expect that the 16384 byte response body would be a WordPress error page.
Either 404 or 403.
To test how your server is responding to the Domain Validation request from comodo you could create a test validation file named
C7FBC2039E400C8EF74129EC7DB1842C.txt in the
public_html/subdomain/.well-known/pki-validation/ directory with the content
c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f
comodoca.com
10af9db9tu
then try to access it using a browser on the url
http://subdomain.domain.com/.well-known/pki-validation/C7FBC2039E400C8EF74129EC7DB1842C.txt
Look for error responses or redirects (The address bar being different to http://subdomain.domain.com after page load)
Error responses or redirects will cause the http Domain Validation to fail.

it displays the data entered in the txt file on the browser

 

[1oann1s]

I'd also like to add the following: Once again I deleted the subdomain, deleted the folder and recreated the subdomain having the "Use a Global DCV Passthrough instead of .htaccess modification (requires EA4)" enabled, with no data at the subdomain. It failed again. On the other hand, on another account i created another subdomain, updated ns, and it worked again like a charm. It seems that in the only case i really need the autossl, is the one i cannot get it to work!

 

[1oann1s]

Hello,

Feel free to open a support ticket using the link in my signature if you'd like us to take a closer look.

Thanks!

Michael, also did that thanks

 

[fuzzylogic]

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

 

[1oann1s]

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

Dear fuzzy.
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...

 

[1oann1s]

Oh yes and also tried the outlined steps in your last suggestion (deleted the .well-known folders), still its similar to deleting the entire sub-domain and their physical folders which i had tried before.

 

[fuzzylogic]

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...

I had not imagined that setup. So that would be???

Local cPanel account for domain.com
DNS entry pointing domain.com to an IP NOT on this local cPanel server
Subdomain subdomain.domain.com on the local cPanel account for domain.com
DNS entry pointing subdomain.domain.com to the IP that IS on this local cPanel server

I do believe that cPanel (powered by Comodo) ssl certificates use Multi Domain Certificates (sni).
I also believe that they use the cPanel accounts main domain as the common name for AutoSSL.
So for the setup described above I would expect AutoSSL to create a single ssl cert with...
domain.com (common name)
subdomain.domain.com

To validate it would create...

public_html/.well-known/pki-validation/your-hash.txt
and try to validate it at
http: domain.com/.well-known/pki-validation/your-hash.txt

public_html/subdomain/.well-known/pki-validation/your-hash.txt
and try to validate it at
http: subdomain.domain.com/.well-known/pki-validation/your-hash.txt

The first validation would fail because the URI points to a different server, so does not have the validation file on it.
It may even have a htaccess file with entries to cause a 403 for the request.