Disabling AutoSSL Issue
Hi friends,
I have ~400 cPanel accounts, each with a WordPress installation inside. My customer go straight to their WordPress admin login and don't know about cPanel. I manage their cPanel accounts through API calls.
Some of my customers want to use SSL. I have the autossl feature disabled by default on all accounts, but when a customer wants SSL, I enable it with this API call:
This works fine... the problem is, if the customer decides that they don't want SSL right now (i.e. if their website has inlined dependencies that are non-SSL), I cannot then disable autossl no matter what I do... I have tried sending the reverse API call to set features={"autossl":"0"} but Apache still automatically redirects all incoming requests from domain.com to domain.com with ssl even if that lands them on an error page due to a self-signed or incorrect cert. I have explored all through WHM and the cPanel account pages but I don't see any way to turn off this automatic undesired forced redirect onto
https://ns1.example.com:2087/xml-api/add_override_features_for_user?api.version=1&user=aa474402&features={"autossl":"0"}
-- that's features={"autossl":"1"}
This works fine... the problem is, if the customer decides that they don't want SSL right now (i.e. if their website has inlined dependencies that are non-SSL), I cannot then disable autossl no matter what I do... I have tried sending the reverse API call to set features={"autossl":"0"} but Apache still automatically redirects all incoming requests from domain.com to domain.com with ssl even if that lands them on an error page due to a self-signed or incorrect cert. I have explored all through WHM and the cPanel account pages but I don't see any way to turn off this automatic undesired forced redirect onto
-
Hi @0884094, I've tried to replicate this on a 66 server, but am unable to. When AutoSSL follows the package default, the 'FEATURE-AUTOSSL' directive will not exist in `/var/cpanel/$username'. When you run the 'add_override_features_for_user' whmapi1 call, the user file is updated with 'FEATURE-AUTOSSL=1' to enable it, and 0 to disable it. I've tested this as below # grep FEATURE-AUTOSSL /var/cpanel/users/$user # whmapi1 add_override_features_for_user user=$user features=%7B%22autossl%22%3A%221%22%7D # grep FEATURE-AUTOSSL /var/cpanel/users/$user FEATURE-AUTOSSL=1 # whmapi1 add_override_features_for_user user=$user features=%7B%22autossl%22%3A%220%22%7D # grep FEATURE-AUTOSSL /var/cpanel/users/$user FEATURE-AUTOSSL=0 # /usr/local/cpanel/bin/autossl_check --user=$user This system has AutoSSL set to use "cPanel (powered by Comodo)". "$user" does not have the required feature "autossl".
Do you see the same? I believe there is confusion with what disabling AutoSSL actually does for a user. This prevents it from applying any new SSL CRT's via the AutoSSL system; it doesn't remove the installed SSL CRT's. Apache still automatically redirects all incoming requests
Redirects are done by the user's '.htaccess' file or even the applications PHP database(e.g. site_url in wp_options on Wordpress installs). I don't believe AutoSSL add's any http -> https redircts in the users '.htaccess', just redirects for DCV file validation. Thanks,0 -
Hi cPWilliamL, thank you very much for looking into this. You're right, the AutoSSL feature does not force redirects. It is now working very well for me. A year ago I'd put this deep in my core Apache conf file to make all SSL requests use HTST (back when the only SSL site was my admin site, and I wanted to score A+ on ssllabs): <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains;" Header set Content-Security-Policy "upgrade-insecure-requests" env=HTTPS </IfModule> Once I started experimenting with SSL, my browsers saw the HTST header and flagged my test domains as always-SSL and so would "redirect" there automatically forever no matter else I did, even for requesting static files after forcibly removing all certs... I also had some confusion with the WordPress site_url and my own database caching logic... in the end I just assumed it was ain cPanel... anyway it really helps to get a sanity check from someone else, so thanks again for taking the time to debug something that's not your issue. 0
Please sign in to leave a comment.
Comments
2 comments