How to allow certbot on an access controlled domain 443? Apache


This is an embarrassing situation for me.

This is a variant of what I have asked here: How to allow certbot on an access controlled domain?

Here 80 redirects to 443. Thus I have added the following to 80:

	<Directory /var/www/htdocs/path/to/site/>
	<IfModule mod_rewrite.c>
		RewriteEngine on
		RewriteBase /
		RewriteCond %{REQUEST_URI} !^.well-known/acme-challenge
		RewriteRule ^(.*)$1 [R=301,L]

This worked six months ago and three months ago. Now I get the Type: unauthorized Detail: Invalid response from … error.

This is a bit irritating to me since it worked twice before. The setup remained unchanged during the past six months. I have no idea how to configure Apache to make this work again and I have no idea why it does not work for the third and more times.

Needless to say that DNS challenge is no option for me. I found a suggestion for NGINX but not for Apache.

In this case adding

        <Location /.well-known/acme-challenge>
            Require all granted

does not work. My question is probably as frustrating as it is for me that it does no longer work.



Have you tried to place a sample file under the prospective folder and see if it reflects in http mode (not redirect to https)?

Thank you


Hi @kghbln

I don’t use that. But there are a lot of samles that


starts with /

So you should test

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge


RewriteCond %{REQUEST_URI} !^/foo/bar$


EDIT: never mind, I think @JuergenAuer has the right idea.


Sorry for taking so long to reply. Unfortunately I am still out of luck:

	<Directory /var/www/htdocs/path/to/site/>
	<IfModule mod_rewrite.c>
		RewriteEngine on
		RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge
		RewriteRule ^(.*)$1 [R=301,L]

Does not work. :frowning:

	<Directory /var/www/htdocs/path/to/site/>
	<IfModule mod_rewrite.c>
		RewriteEngine on
		RewriteBase /
		RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge
		RewriteRule ^(.*)$1 [R=301,L]

Does not work either. :frowning:

	<Directory /var/www/htdocs/path/to/site/>
	<IfModule mod_rewrite.c>
		RewriteEngine on
		RewriteBase /
		RewriteCond %{REQUEST_URI} !^.well-known/acme-challenge
		RewriteRule ^(.*)$1 [R=301,L]

This worked twice, but no longer. :frowning:

Placing a file in does work, i.e. the file is accessible via the internet without the requirement to authenticate. All adaptations were done for 80.

I am really puzzled and still have no idea what is going on.


Then share your domain name and the complete error message.

This isn’t enough.

PS: Use 1234 as filename. Letsencrypt want’s a file without a file extension.


This is the error I am getting.

Type: unauthorized
Detail: Invalid response from
    2.0//EN\">\n<html><head>\n<title>404 Not
    Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"


Removing the file extension does not change the situation. The file is still accessible without authentication.


Are you sure you entered the correct webroot path?


I wonder why this worked for the past two renewals in this environment which is unchanged since it was set up. I will check.


This is not the error. The domain name is missing. Please read that (opening a new Topic in Help):

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

Moved to “Help”


If I want to disclose the domain I would already have done so. I had hoped that allowing to challenge an authenticated domain is a generic issue and not an edge case. Anyways I still have to check for the root.


Hi @kghbln,

You don’t need the RewriteBase and the right regex for the RewriteCond is this

RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge

Anyway, using your above conf should work without these changes.

Are you using your browser to test it?, because if you are using HTTP Strict Transport Security (HSTS) you won’t get accurated results, instead use curl, put a file like 1234 in /var/www/htdocs/path/to/site/.well-known/acme-challenge/

echo 'test file' > /var/www/htdocs/path/to/site/.well-known/acme-challenge/1234

and try to get the file:

curl -ikL

If that doesn’t work you should post your entire conf or maybe you could use an Alias directive pointing to another directory that doesn’t need auth to access it.



Thanks a lot for all your help so far. I can feel the fatigue and ennui you have trying to help me.

This works

certbot renew gives

Type: unauthorized
Detail: Invalid response from

I now not just edited 80 which worked perfect the past two challenges. I now moreover added all the stuff to 443 too with discouraging results.

This does not work either and gives the same unauthorized error as the original config I had in my VirtualHost. I will have another look. I just wonder what change during the past three months.


I will now try to do the alias stuff.


Hi @kghbln,

Before trying the alias, could you please show the contents of /etc/letsencrypt/renewal/ ?


#17 = /var/www/htdocs/path/to/site

The /var/www/htdocs/path/to/site/ is identical to what is specified in Directory if this is what you would like to check.

# renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

# Options used in the renewal process
authenticator = webroot
installer = None
account = obfuscated
[[webroot_map]] = /var/www/htdocs/path/to/site

I am on a Debian 8


Yes I would like to check that and looks fine. Your domain has A (IPv4) and AAAA (IPv6) records?.


Yes I would like to check that and looks fine. Your domain has A (IPv4) and AAAA (IPv6) records?.

It should not but I will have to check. Anyways if it has both IP will point to the same server. Other challenges on this server work perfect. However the domain does not require authenification.


I think I now know where the issu originates:

Certbot is issuing the following

Cert is due for renewal, auto-renewing...
Starting new HTTPS connection (1):
Renewing an existing certificate
Performing the following challenges:

Well, trying to start a HTTPS connection will imperatively fail here. Access is only possible via a HTTP connection.

Even disabling port 443 for this subdomain does not change a thing. It tries to access HTTP via a HTTPS connection as it looks to me.

Quite frankly, I am in dispair now.