Keep cPanel from using SSL on .well-known for AutoSSL Global DCV Passthrough method

Monday, April 16th, 2018
Last Updated:
Friday, June 22nd, 2018

Disclaimer: Accessing the information on this page means you agree to the Sites Terms of Service

cPanel is like the Windows of website hosting platforms. It's got a great GUI to click around on, lots of power under the hood but rarely "just works".

It seems like you always have to muck with the most mundane stuff in order to make cPanel work right and they've added yet another thing to muck with: AutoSSL Renewal.

When using the Global DCV Passthrough method, cPanel has it's own way of checking the domain, then requesting a certificate and issuing it to a domain. The problem arose somewhere around the first quarter of 2018 where the AutoSSL system refused to renew an SSL certificate if there were ANY redirects on the domain. This includes a redirect from non-ssl to ssl and non-www to www. That's either 1 or 2 redirects depending on how you have it setup and the DCV method expects ZERO redirects. In otherwords, good luck re-directing your website to www or https if you want cPanel to automatically renew your ssl cert unless you add very specific rules to your .htaccess files.

This is a major problem, because any webmaster worth their weight in gold, will force all requests to redirect to https because let's face it... that's the WHOLE POINT of the SSL certificate in the first place...

So yes. When the cPanel AutoSSL is trying to renew your certificate and checking to make sure your domain is valid, it is doing it over a non-secure connection. Makes total sense! *sarcasm* At least it's contained to the server itself... or is it...

In all honesty, this "could" be completely mitigated if the devs at cPanel would finally after two decades, implement the ability to force both www and(or) ssl on a domain within the control panel. There was a feature request out there for it, but it got erased due to a backup failure... This feature could basically create a direct rebuild of the httpd.conf file so requests are served directly from apache and if the devs were thinking, could allow them to make sure their .well-known folder isn't being served as https, relieving the whole headache for the rest of us. I'm a little boned by this topic if you can't tell.

Rant out of the way, let's set a redirect for all of your domains so they all force https so you don't have to do it in each and every single .htaccess file on the server.


This is assuming, that you have the AutoSSL enabled for all of the domains on your server. If you don't have certain domains getting SSL certs, they're going to be forced to https with the following steps. You're fore-warned.


  • If you HAVE already added a rewrite rule to each of your domains .htaccess files, you'll have to comment those out if you go this global route.
  • These instructions assume you have full root access to the server. If you're on a shared hosting plan, you'll have to add stuff to each domains .htaccess file.
  • The grand instructions are located out at:
  • sudo I'm one of those really bad linux people who run things as root... so don't forget to run the following as sudo ;-)

Create Directories

First, we need to create the std directory so it looks like:


STD stands for "Standard" or Non-SSL requests. Since we want to redirect non-ssl requests over to ssl, we put this in the std folder. (For ssl requests, you would create an ssl folder inside userdata)

Note 1: You don't have to do the entire server. You can choose to do just a specific user account, or you can choose to do a specific domain. (View instructions)

Note 2: The cPanel instructions say to put your .htaccess rules inside "includename.conf". This file name is simply a placeholder for "create-any-file-name-you-want.conf". When you run the rebuild script later, it checks for the wildcard *.conf and applies the rules that are in all .conf files, regardless of the name. You can call it "fluffy-cats-are-cool.conf" for all I care...

Create ssl.conf

Inside the std folder, let's touch a file called ssl.conf

cd /etc/apache2/conf.d/userdata/std/
touch ssl.conf

You'll end up with: /etc/apache2/conf.d/userdata/std/ssl.conf

Next, let's edit the ssl.conf file

vi ssl.conf

Let's add the necessary bits to not only force https, but we're also going to add the necessary rule conditions that will EXCLUDE the .well-known folder. Shout-out to cPanelMichael for the necessary bits to make this work.

Insert the following:

RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Note the cPanel portion of the rule. It will ONLY work on the DCV related files. Any other file that does not match the regex string, will follow the regular rules. This ensures that ONLY the DCV file can be served as non-ssl.

Save the file and exit the editor

Rebuild & Reboot Apache httpd.conf

First, let's re-build the apache httpd.conf file:


Next, let's reboot apache the way cPanel says to reboot it:


Assuming everything went well, you should be golden! Go test things out and marvel in wonder!

Post Comment

(If you're a human, don't change the following field)
Your first name.
(If you're a human, don't change the following field)
Your first name.


I am using AWS S3 and Route 53 for all my client websites. This works great in avoiding a hardcoded IP address for the A record, by having the S3 bucket redirect all requests to www -- then in Route 53 using an alias record for non-www, over to the S3 endpoint. Finally, a CNAME record gets the route to my actual server. It all works magically. However, all requests end up landing at www, either directly or via 302.

Now trying to use autoSSL the darn thing refuses to validate DCV since it demands to read the file from the non-www location. It gets a 302 back for the redirect to www -- and then says " lose". Since when are we so paranoid about www versus non-www for the same domain name? Why??


I appreciate your candor, and I'd love to help however I can! Feel free to email us so we can take a look at the feature request you submitted last year, and get it back on the site. community [at] cpanel [dot] net