Does an HTTPS Redirect Break Let's Encrypt Renewal?

Short answer: Usually not. Let's Encrypt follows redirects when it fetches /.well-known/acme-challenge/<token>, including a redirect from HTTP to HTTPS. What breaks renewal is a rule that changes where that request ends up: a redirect that drops the path, sends it to another host or port, or a catch-all rewrite that serves a page instead of the token file. The fix is one passthrough line above those rules, and the test is fetching a real file over plain HTTP.

The symptom

Renewal fails, often weeks after the .htaccess change that caused it, because nothing exercises the challenge path until the next renewal. The certificate keeps working until it expires, so the site looks fine the whole time. Then the renewal log shows the challenge URL answering with a 404, a 403, or an HTML page where a short token string should be.

That delay is why people search for this after the fact. The edit and the outage are months apart, and nobody connects them.

What the challenge actually needs

The HTTP-01 challenge is defined in RFC 8555, section 8.3. The certificate authority builds the URL http://{domain}/.well-known/acme-challenge/{token}, sends a GET to port 80, and checks that the body is the exact key authorization your ACME client wrote. The /.well-known/ prefix itself comes from RFC 8615, which reserves well-known URIs for site-wide metadata, and acme-challenge is one of the names in IANA's well-known URI registry.

On redirects, RFC 8555 says the server "SHOULD follow redirects". Let's Encrypt's challenge types page is more specific: its HTTP-01 check follows up to 10 redirects, only to http: or https:, only to ports 80 or 443, and does not validate the certificate on an HTTPS hop, because it may meet a self-signed or expired one.

So a redirect is not the problem. Arriving somewhere other than the token file is.

What breaks it and what does not

We tested each rule on Apache 2.4.68 in a local container, with a token file at /.well-known/acme-challenge/TOKEN123, and requested it over plain HTTP.

Rule above the challenge path	What the request got	Renewal with Let's Encrypt
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]	301 to the same path on HTTPS	Works, if HTTPS serves the file
RewriteRule ^ https://example.test/ [L,R=301]	301 to the home page	Fails: the body is HTML, not the token
Catch-all rewrite into a build folder, RewriteRule ^(.*)$ _site/$1 [L]	404	Fails: the file is not in _site/
A passthrough for acme-challenge above all of these	200 with the token text	Works

Other causes in the same family:

• A www to bare-domain redirect, or the reverse, where the token was written to the other host's document root.
• A redirect to a port other than 80 or 443, which Let's Encrypt refuses.
• IP blocking, password protection or a bot filter in front of the site. DreamHost's Let's Encrypt guide names IP blocking, rewrite rules and password protection as causes of a failed install.
• A certificate authority other than Let's Encrypt. The RFC says SHOULD, not MUST, so a CA that does not follow redirects is allowed.

The fix

Put the passthrough first in the root .htaccess, before any redirect or catch-all rewrite. The - substitution in Apache's RewriteRule directive means "pass the path through untouched", and the L flag stops the rules below it from running:

RewriteEngine On

# ACME HTTP-01: serve the token file as-is, over plain HTTP, before anything else.
RewriteRule ^\.well-known/acme-challenge/ - [L]

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]

# ...catch-all and front-controller rules go below this point

The redirect is the one DreamHost's own force-HTTPS article shows, and DreamHost's Let's Encrypt guide suggests a passthrough of its own, RewriteRule ^.well-known/(.*)$ - [L], for sites that break when .htaccess is switched off. Its pattern covers all of /.well-known/. Ours covers only acme-challenge, so other well-known files such as security.txt still get the HTTPS redirect.

If you rewrite everything into a build folder, the passthrough matters more than the redirect does. That rule is an internal rewrite, not a redirect, so following redirects cannot rescue it.

A second .htaccess inside .well-known

Check for one. In our test, a .well-known/.htaccess containing its own RewriteRule lines replaced the root file's rules for that folder completely: neither the path-dropping redirect nor the passthrough ran. That is Apache's default, and RewriteOptions Inherit changes it. A nested Require all denied answered 403 even with the root passthrough in place.

How to verify

Ask for a challenge-shaped URL over plain HTTP and see where it lands. Any name will do; this one does not exist, so a 404 at the end is expected:

curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" \
  http://example.com/.well-known/acme-challenge/check-123
curl -sL -o /dev/null -w "final %{http_code} %{url_effective} after %{num_redirects} redirect(s)\n" \
  http://example.com/.well-known/acme-challenge/check-123

On a correctly configured site we checked, that printed 301 -> https://.../.well-known/acme-challenge/check-123 and then final 404 ... after 1 redirect(s). The path survived the hop. If the final URL is your home page, another host or a non-standard port, that is your fault.

A 404 does not prove the path works, though. A path that is never redirected and never served also answers 404. For the real test, put a small file with known text in .well-known/acme-challenge/, fetch it with curl -sL, compare the body, then delete it. As in why curl exits 0 on a 404, check the status and the body, not just that curl finished.

If you run Certbot, its renewal documentation gives certbot renew --dry-run, which runs against the Let's Encrypt staging server and saves nothing. The webroot plugin notes warn that a server treating /.well-known specially must still serve files from acme-challenge. We did not run Certbot for this article.

The near-miss that prompted this

On one of my own sites in September, a force-HTTPS rule was added at the top of an Apache .htaccess, above the line that passes /.well-known/ through. A second AI coding session reviewing the change caught it before it shipped. The comment just above that passthrough already said why the order mattered: breaking it shows no symptom until the certificate lapses.

Moving the rule below the passthrough was right. The reason given, that any redirect above it intercepts renewal, was stronger than Let's Encrypt's own documentation supports. On that site the passthrough matters mainly because every other request is rewritten into a build folder, the third row of the table.

The hosting points the same way. The sites are on DreamHost, the same setup as deploying a Node.js server on DreamHost. Plain-HTTP requests to /.well-known/acme-challenge/ on that site and three others, this one included, all get a 301 to the same path on HTTPS. One of them passes that path through in .htaccess before its own redirect and still answers 301, so the redirect comes from the host's panel setting, ahead of the file.

All four have Let's Encrypt certificates issued in October 2026, with the redirect in front. That is not proof that renewals use HTTP-01: DreamHost's guide says it adds a .well-known directory at install, but not how renewals are validated. It is consistent with a same-path redirect being harmless.