Let's Encrypt requires inbound HTTP requests on port 80 to complete the ACME HTTP-01 challenge used for both new certificate issuance and automatic renewals. A global HTTP-to-HTTPS redirect breaks this process because the validation token cannot be retrieved from the /.well-known/acme-challenge directory. The fix is to insert an exception rule that serves these specific paths over plain HTTP before any redirect logic is evaluated.
Place the exception first in your rewrite configuration. The sections below give the precise XML for IIS web.config, the Helicon Ape directive for IIS, and the equivalent Apache .htaccess rule. These changes let tools such as win-acme or Certify The Web perform unattended renewals while keeping your site HTTPS-only for all other traffic.
#Why the ACME Challenge Needs an Exception
The Let's Encrypt CA fetches a unique token from http://yourdomain.com/.well-known/acme-challenge/{token} to prove domain control. Any HTTP 301 or 302 redirect to the HTTPS version causes the validation to fail. The protocol deliberately uses HTTP to avoid depending on a working TLS configuration during initial issuance. Without an explicit bypass, even a correctly installed certificate cannot be renewed automatically when it expires in 90 days.
#IIS URL Rewrite Configuration
Open or create the web.config file in the root folder of your IIS website. Locate the <rewrite><rules> section (create it if absent) and insert the following rule as the very first child element. It must precede any redirect rules so that matching requests are short-circuited immediately.
<rule name="ACME / Let's Encrypt Verification" stopProcessing="true">
<match url="^\.well-known(.*)" />
<action type="None" />
</rule>
The stopProcessing="true" attribute prevents further rule evaluation. The regex ^\.well-known matches the required directory and any files beneath it. After saving, IIS applies the change without a restart. Confirm the rule order in the IIS Manager URL Rewrite module GUI if you prefer a visual editor.
#Helicon Ape and Apache .htaccess Rules
For servers using Helicon Ape on IIS or native Apache, add a single RewriteCond immediately after the RewriteEngine On line in your root .htaccess file. This condition excludes the ACME challenge path from subsequent rewrite or redirect rules.
RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge
The exclamation mark negates the match so the following RewriteRule is skipped. Use the identical line for both Helicon Ape and standard Apache. If you have multiple .htaccess files, the rule must be present in the one that processes the root URI.
#Testing the Configuration
After applying the rules, verify that HTTP requests to the challenge path are not redirected. Perform these checks in order:
- Create a test file at .well-known/acme-challenge/test.txt containing the text "ACME test successful"
- Request the URL http://yourdomain.com/.well-known/acme-challenge/test.txt with curl or a browser in private mode
- Confirm the response returns HTTP 200 with your test content and no Location header
- Trigger a staging renewal with your ACME client using the --test flag to validate end-to-end operation
#Common Pitfalls and Troubleshooting
- Rule ordering: the exception must evaluate before any catch-all redirect; move it to the top if renewals still fail
- Regex escaping: the dot in \.well-known must be escaped or it will match any character before "well-known"
- Proxy or CDN caching: purge any front-end cache after changes because an earlier cached redirect can persist
- Folder permissions: ensure the .well-known directory grants read access to the IIS application pool or Apache user
Implement the exception exactly as shown, test the HTTP path, then schedule your automatic renewal. This configuration maintains both security and reliable certificate lifecycle management on Windows and Linux hosting environments.
Comments
No comments yet