htaccess - Allow Let's Encrypt to Validate and Renew

SSL & HTTPS | Updated March 2026

If Let's Encrypt cannot validate your domain because of .htaccess rules (password protection, IP restrictions, or redirects), add this line before all other rewrite rules in your .htaccess file: RewriteRule ^\.well-known/ - [L]. This tells Apache to stop processing rewrite rules for the .well-known directory, allowing ACME challenge files to be served normally. On Ultra Web Hosting, AutoSSL handles this automatically — you typically only need this rule if you have custom restrictions in place.

RewriteRule ^\.well-known/ - [L]

01. How Let’s Encrypt Validation Works

Let’s Encrypt uses the ACME protocol (Automatic Certificate Management Environment) to verify that you control a domain before issuing an SSL certificate. The most common method is HTTP-01 validation, which works like this:

1. The ACME client (AutoSSL, Certbot, etc.) creates a unique token file inside .well-known/acme-challenge/ in your site’s document root.
2. Let’s Encrypt’s validation servers make an HTTP request to http://yourdomain.com/.well-known/acme-challenge/<token> to retrieve the file.
3. If the server returns the correct token, domain ownership is confirmed and the SSL certificate is issued or renewed.

If anything in your .htaccess file blocks, redirects, or password-protects this path, validation will fail and your SSL certificate will not be issued or renewed.

02. The .well-known Directory

The .well-known directory is a standardized location defined by RFC 8615 for site-wide metadata. Let’s Encrypt uses the .well-known/acme-challenge/ subdirectory specifically for validation tokens. A typical challenge file path looks like:

/home/username/public_html/.well-known/acme-challenge/abc123def456...

This directory is created and cleaned up automatically during the validation process. You do not need to create it manually unless you are troubleshooting.

03. .htaccess Rules That Block Validation

Several common .htaccess configurations can prevent Let’s Encrypt from reaching the challenge files. Below are the most frequent causes and the fix for each.

HTTP to HTTPS Redirects

The most common cause of validation failure. If your .htaccess redirects all HTTP traffic to HTTPS, the ACME validation request gets redirected before the token can be read.

Problem — redirect blocks validation:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Fix — exclude the challenge directory:

RewriteEngine On
RewriteRule ^\.well-known/ - [L]

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Placing the exception before the redirect ensures ACME requests are served as-is.

Password-Protected Directories (Basic Auth)

If your entire site or document root is password-protected with .htpasswd, the validation server cannot authenticate and the request is denied.

Problem — entire site requires a password:

AuthType Basic
AuthName "Restricted"
AuthUserFile /home/username/.htpasswd
Require valid-user

Fix — create a separate .htaccess inside .well-known/:

# /public_html/.well-known/.htaccess
Satisfy any
Allow from all

Alternatively, use SetEnvIf in your main .htaccess:

AuthType Basic
AuthName "Restricted"
AuthUserFile /home/username/.htpasswd

SetEnvIf Request_URI "\.well-known/" allow
Order allow,deny
Allow from all
Deny from env=!allow
Satisfy any
Require valid-user

IP Address Restrictions

If your .htaccess restricts access to specific IP addresses, Let’s Encrypt’s validation servers will be blocked.

Problem — access limited to specific IPs:

Order deny,allow
Deny from all
Allow from 192.168.1.100

Fix — add a rewrite exception before the IP rules:

RewriteEngine On
RewriteRule ^\.well-known/ - [L]

Order deny,allow
Deny from all
Allow from 192.168.1.100

WordPress and CMS Rewrites

WordPress, Joomla, Drupal, and other CMS platforms use rewrite rules to route requests through their front controller. These rules usually do not interfere because they include RewriteCond %{REQUEST_FILENAME} !-f, which skips files that actually exist on disk.

However, if you’ve added custom HTTPS redirects or security rules above the WordPress block, those can still cause issues. Always place the .well-known exception as the very first rewrite rule in the file:

RewriteEngine On
RewriteRule ^\.well-known/ - [L]

# Your HTTPS redirect
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

# BEGIN WordPress
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Blanket Deny Rules and ModSecurity

Some security configurations use broad deny rules that block requests to hidden (dot) directories:

Problem:

RedirectMatch 403 /\.

This returns a 403 Forbidden for any URL containing /. — which includes /.well-known/.

Fix — add the rewrite exception before the deny rule:

RewriteEngine On
RewriteRule ^\.well-known/ - [L]

RedirectMatch 403 /\.

04. Complete .htaccess Template

Here is a recommended .htaccess layout that ensures Let’s Encrypt validation works alongside HTTPS redirects and WordPress:

RewriteEngine On

# -- Allow Let's Encrypt validation --
RewriteRule ^\.well-known/ - [L]

# -- Force HTTPS --
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

# -- Force www (optional) --
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

# -- WordPress --
# BEGIN WordPress
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

05. AutoSSL on Ultra Web Hosting

All Ultra Web Hosting shared, reseller, and managed accounts include AutoSSL, which automatically provisions and renews Let’s Encrypt SSL certificates for your domains. AutoSSL runs on a regular schedule and handles validation at the server level.

In most cases, AutoSSL works without any manual .htaccess changes. You may need to add the .well-known exception if:

• Your site’s .htaccess password-protects the document root
• You have IP-based access restrictions in .htaccess
• Custom rewrite rules redirect or block requests to hidden directories
• A security plugin (Wordfence, iThemes, All In One WP Security, etc.) adds restrictive .htaccess rules

You can check the current AutoSSL status of your domains in cPanel under SSL/TLS Status. If a domain shows a validation error, review your .htaccess using the rules above, then click “Run AutoSSL” to retry.

06. Troubleshooting Validation Failures

If Let’s Encrypt or AutoSSL cannot validate your domain, work through these checks:

1. Test the challenge path manually. Open a browser or use curl to request http://yourdomain.com/.well-known/acme-challenge/test. You should get a 404 Not Found (file doesn’t exist, but the directory is accessible). If you get a 301 redirect, 403 Forbidden, or a login prompt, your .htaccess is the problem.
2. Check from the command line. SSH into your account and run:
   curl -I http://yourdomain.com/.well-known/acme-challenge/test
   Look at the HTTP status code. A 200 or 404 is acceptable. A 301, 302, 403, or 503 indicates a blocking rule.
3. Review your .htaccess file. Open .htaccess in your document root and look for HTTPS redirects, Deny directives, AuthType blocks, or RedirectMatch rules that could intercept the request.
4. Check for nested .htaccess files. If there is a .htaccess file inside the .well-known/ or .well-known/acme-challenge/ directory itself, its rules may override the parent.
5. Verify DNS resolution. The domain must resolve to the correct server IP. If the domain points to a CDN like Cloudflare, make sure the DNS record is set to DNS Only (gray cloud) during validation, or that your CDN is not blocking the challenge path.
6. Run AutoSSL again. In cPanel, go to SSL/TLS Status and click “Run AutoSSL” after making your changes. AutoSSL will re-attempt validation for any domains that previously failed.

07. Additional Tips

• Don’t block .well-known in robots.txt. While robots.txt does not affect Let’s Encrypt (it’s not a search engine crawler), blocking this path can cause confusion during debugging.
• Security plugins: WordPress security plugins like Wordfence, Sucuri, All In One WP Security, and iThemes Security can add restrictive rules to .htaccess. If validation fails after installing a security plugin, check what rules it added and apply the .well-known exception above them.
• Subdirectory installs: If your site runs from a subdirectory (e.g., /blog/), the .well-known directory is still served from the document root, not the subdirectory. The exception rule belongs in the root .htaccess.
• Addon and subdomain document roots: Each addon domain and subdomain has its own document root. If a specific domain is failing validation, check the .htaccess in that domain’s document root, not just the main account’s public_html.
• Wildcard certificates: Wildcard certificates (*.yourdomain.com) require DNS-01 validation instead of HTTP-01. The .htaccess rules in this article do not apply to wildcard validation — that process uses DNS TXT records instead.

Quick Recap: Let’s Encrypt .htaccess Fix

1. Add the exception rule — RewriteRule ^\.well-known/ - [L] as the very first RewriteRule in your .htaccess
2. Test the path — visit http://yourdomain.com/.well-known/acme-challenge/test and confirm you get a 404, not a redirect or 403
3. Run AutoSSL — go to cPanel → SSL/TLS Status → Run AutoSSL to retry validation

Last updated March 2026 · Browse all SSL articles · See also: SSL Certificates and HTTPS · Redirect HTTP to HTTPS · .htaccess Guide