AutoSSL - htaccess whitelist
From what I understand, verification of the domains for AutoSSL Let's Encrypt plugin, means that the domain is verified by accessing a temporary file name from public_html.
In my tests, none of my domains allow this validation because of various blocks/restrictions imposed by the htaccess file.
Can someone post the relevant temporary files that we need to whitelist in our htaccess, in order to allow domain validation to complete?
Thank you.
PS:
unlike most people, my servers run a very restrictive htaccess that block everything and only allows known things that should be accessible from the internet.
*edit*
I did some tests and I found 3 things that can break AutoSSL with Lets Encrypt:
1) The first, is an htaccess that enforces SSL connections.
For example, this will break certificate creation:
2) The second, is blocking access to /.well-known/acme-challenge/ and in my case I have to explicitly allow access to that directory. 3) The third, is to blocking access to those temporary tmp files created by AutoSSL that look like: 1234.BIN_AUTOSSL_CHECK_PL__.randomstring.tmp. All three can be avoided by adding some clever RewriteCond rules.
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
2) The second, is blocking access to /.well-known/acme-challenge/ and in my case I have to explicitly allow access to that directory. 3) The third, is to blocking access to those temporary tmp files created by AutoSSL that look like: 1234.BIN_AUTOSSL_CHECK_PL__.randomstring.tmp. All three can be avoided by adding some clever RewriteCond rules.
-
I can confirm that #1, enforcing SSL via .htaccess, does indeed break AutoSSL with Let's Encrypt. I commented out those two lines in .htaccess and then AutoSSL worked perfectly. Although things are ok now, as the root domain and all of the subdomains are secured, unless I leave these two lines commented out permanently (something I would rather not do), I'm guessing this will fail again when the root domain certificate tries to renew in 3 months. 0 -
You are right. Here is my solution so far, exclude the files accessed by AutoSSL and Let's Encrypt from being redirected. RewriteCond %{HTTPS} off RewriteCond %{REQUEST_URI} !^/\d+\.BIN_AUTOSSL_CHECK_PL__\.\w+\.tmp$ [NC] RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/ [NC] RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
If you think I have made any mistakes or you can improve the above, please do post your thoughts. Thank you. PS: Maybe the [NC] is not needed?0 -
Your code works perfect for me! Though I did encounter another situation where Let's Encrypt via AutoSSL was failing. When using HTTP authentication I had to modify the section that triggers the password protection so that it only matches against certain files, that way AutoSSL doesn't get prompted for a password, which causes the auto-generation to fail. This is by no means ideal for everyone, as it's now only looking for certain types of files before prompting for a password, so it isn't 100% secure, but it works for my particular situation. I tried to find a better method where it only excluded the Let's Encrypt AutoSSL files but I couldn't seem to get it to work. AuthType Basic AuthName "tools" AuthUserFile "/home/user/.htpasswds/subdomains/sub/passwd" require valid-user 0 -
I'm glad it worked for you! Here is an updated version that also enforces "www." on the domain but still allows AutoSSL to verify the domain without it. I'm sorry its of no help to those who want to password protect the entire public_html directory. # Enforce www. on the domain RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteCond %{REQUEST_URI} !^/\d+\.BIN_AUTOSSL_CHECK_PL__\.\w+\.tmp$ RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/ RewriteRule .* https://www.%{HTTP_HOST} [L,R=301] # Enforce https SSL/TLS RewriteCond %{HTTPS} off RewriteCond %{REQUEST_URI} !^/\d+\.BIN_AUTOSSL_CHECK_PL__\.\w+\.tmp$ RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/ RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Ideally, we shouldn't need to be doing these tricks. I am looking at the implementation of another hosting tool (Aetolos) and the trick there was to use a universal directory for ".well-known" that is outside of the public_html, thus it does not get affected by whatever custom htaccess is being used. Maybe cPanel could use that idea in their AutoSSL plugin.0 -
Hello, To update, internal case CPANEL-6147 is open to address an issue where certain rewrite conditions in .htaccess files prevent Let's Encrypt and Comodo from completing the domain validation process. I'll update this thread with more information on this case as it becomes available. Additional information on testing the validation process is available at: cPanel & WHM"s AutoSSL/SSL ordering process Edit: .htaccess rule examples affected by this issue are no longer required. Thank you. 0 -
What's cPanel's oppinion about using this at the beginning of the .htaccess file instead of repeating the htaccess rules for every redirect found? It would be much easier to implement automaticaly. RewriteEngine On RewriteCond %{REQUEST_URI} /[A-F0-9]{32}\.txt$ [OR] RewriteCond %{REQUEST_URI} /\.well\-known\/acme\-challenge RewriteCond %{REQUEST_FILENAME} -f RewriteRule (.*) $1 [L]
In a month our first certs will be close to expiring so we have to implement this fix before cPanel does. We're going to look for all .htaccess files that contain https and add these lines to them at the beginning of the file. What do you think ?0 -
In a month our first certs will be close to expiring so we have to implement this fix before cPanel does. We're going to look for all .htaccess files that contain https and add these lines to them at the beginning of the file. What do you think ?
I've moved this post to the existing thread that includes manual workarounds, should you prefer alternatives before updating to cPanel version 60. Thank you.0 -
None of the above can be applied automaticaly as they all require editing existing rules. My idea is to add the above to the top of .htaccess files to disable all further rewrites no matter what they are. 0 -
You should be able to use the rules referenced in this post in the same manner if you require a temporary workaround before using cPanel version 60. Thank you. 0 -
I don't see how those ones could be applied automatically, I'm also not sure if you read my initial post that you moved here : We already believe we have the correct lines that can be added automatically to the beginning of our clients htaccess files but just wanted cPanel's opinion on these lines. Instead you have tried to point us to lines that require editing existing rules and not just adding new ones. With 2500+ accounts to check this can't be done manually. 0 -
Your code works perfect for me! Though I did encounter another situation where Let's Encrypt via AutoSSL was failing. When using HTTP authentication I had to modify the section that triggers the password protection so that it only matches against certain files, that way AutoSSL doesn't get prompted for a password, which causes the auto-generation to fail. This is by no means ideal for everyone, as it's now only looking for certain types of files before prompting for a password, so it isn't 100% secure, but it works for my particular situation. I tried to find a better method where it only excluded the Let's Encrypt AutoSSL files but I couldn't seem to get it to work. AuthType Basic AuthName "tools" AuthUserFile "/home/user/.htpasswds/subdomains/sub/passwd" require valid-user
We have a number of clients who run HTTP authentication - and we had to resort to FilesMatch as well. Im not sure if this is practical/possible but having the extension not be .txt would make for a much cleaner rule. Something like .autossl would be fantastic. Then we could just apply redirect/auth rules to files (not) .autossl.0 -
We already believe we have the correct lines that can be added automatically to the beginning of our clients htaccess files but just wanted cPanel's opinion on these lines. Instead you have tried to point us to lines that require editing existing rules and not just adding new ones. With 2500+ accounts to check this can't be done manually.
Hello, An internal case was opened to ensure the changes in cPanel version 60 to account for rewrite rules during the Comodo verification process will work for the specific .htaccess rules referenced in your support ticket. I'll update this thread once an outcome to that case is confirmed. Thank you.0 -
I support the idea of using an extension like .autossl to avoid disturbing existing redirection or access rules in .htaccess. 0 -
Is anyone else still having problems with this? I'm using 60.24 and I am VERIFIABLY still having failures (specifically/particularly for the mail subdomain - the site cert(s) itself does seem to work) when forcing SSL in .htaccess as of Nov/20/2016. 0 -
Hello sehh, You asked: Can someone post the relevant temporary files that we need to whitelist in our htaccess, in order to allow domain validation to complete? 1. In a whitelist htaccess place these in the public_html/.htaccess. I use these and have had no issue with cPanel AutoSSL entering my server. Do not uncomment (remove hashtag) the Comment of either below. You can replace xxx.xxxx.xxx.xxx with an IP. Rules are enabled Order Deny,Allow Deny from all #COMMENT | Allows cPanel, cPanel Autossl and LetsEncrypt SetEnvIfNoCase User-Agent .*ncryp.* good_bot SetEnvIfNoCase User-Agent .*hec.* good_bot SetEnvIfNoCase User-Agent .*omod.* good_bot SetEnvIfNoCase User-Agent .*pane.* good_bot SetEnvIfNoCase User-Agent .*utoss.* good_bot #Allow from xxx.xxxx.xxx.xxx Allow from env=good_bot Rules are disabled #Order Deny,Allow #Deny from all #COMMENT | Allows cPanel, cPanel Autossl and LetsEncrypt #SetEnvIfNoCase User-Agent .*ncryp.* good_bot #SetEnvIfNoCase User-Agent .*hec.* good_bot #SetEnvIfNoCase User-Agent .*omod.* good_bot #SetEnvIfNoCase User-Agent .*pane.* good_bot #SetEnvIfNoCase User-Agent .*utoss.* good_bot #Allow from xxx.xxxx.xxx.xxx #Allow from env=good_bot 2. Since you have 2500+ accounts i suggest placing the above SetEnvIfNoCase in your Apache .httpd file and that should cover all domains in the server. 3. As far as SSL enforcement i use this code and have for several years. Replace example.com with your domains name. I also use this successfully with subdomains. RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://example.com/$1 [R,L]
Hope this helps you out. danielpmc I edited by placing the link into a code box.0 -
Is anyone else still having problems with this? I'm using 60.24 and I am VERIFIABLY still having failures (specifically/particularly for the mail subdomain - the site cert(s) itself does seem to work) when forcing SSL in .htaccess as of Nov/20/2016.
Hello, Could you open a support ticket using the link in my signature so we can take a closer look? You can post the ticket number here and I'll make sure this thread is updated with the outcome. Thank you.0
Please sign in to leave a comment.
Comments
16 comments