.well-known acme-challenge folder does not exist

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. crt.sh | example.com), 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:
certbot renew --dry-run --debug-challenges -v

It produced this output: it said "Everything works, bro, your challenge URL exists & the value inside was sweet. Just Chill !"
But it lied to me the folder /.well-known/acme-challenge/ folder does not exist ! ? ! ?
& When I go to the challenge URL in a browser it's all like 404 dude.

How and where is the /.well-known/acme-challenge/ created?
What permissions does it require?
Can I create the folder and the challenge file myself?

My web server is (include version):
Apache 4.3

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

Camandlines and GUI console
The version of my client is : 2.6.0

It depends what authenticator plugin you are using. The output from Certbot should indicate which authenticator it tried to use.


Not sure what you mean by "authenticator" Here is the output:
certbot renew --dry-run --debug-challenges -v
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/apps.library.newpaltz.edu.conf

Certificate not due for renewal, but simulating renewal for dry run

Plugins selected: Authenticator apache, Installer apache
Simulating renewal of an existing certificate for apps.library.newpaltz.edu

Performing the following challenges:
http-01 challenge for apps.library.newpaltz.edu

Challenges loaded. Press continue to submit to CA.
The following URLs should be accessible from the internet and return the value


Expected value:

Waiting for verification...

Cleaning up challenges

Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/apps.library.newpaltz.edu/fullchain.pem (success)

Great, so you are using the Apache authenticator.

What this does is temporarily modify your Apache configuration so that requests to /.well-known/acme-challenge/ get served from a directory within /var/lib/letsencrypt/.

Once the certificate order is complete, the changes to your configuration get automatically reverted and the challenge response file is deleted.

By the looks of things, everything succeeded. What's the problem?


So far it has not shown any ability to modify my httpd settings. For example to make the certificate work in the first place I had to manually enter the cert and key and chain paths in my old ssl.conf file. Even though the install told me everything went fine.
I have a hard time believing the messages it gives because 2 years ago when I tried it on different but similar sever it was a nightmare to get automatic renewal to work this time I need a way to be certain.

Right now your cert on that domain looks fine. See this SSL Checker site (link here)

Using the --apache plug-in you shouldn't have had to make manual changes unless you also used certonly in the original command.

It sounds like your apache might have some unusual config.

Can you show output of this?

httpd -t -D DUMP_VHOSTS

I think httpd is the right command for your RHEL but might need apachectl or apache2ctl instead.


httpd -t -D DUMP_VHOSTS

VirtualHost configuration:
*:80 apps.library.newpaltz.edu (/etc/httpd/conf/httpd.conf:377)
*:443 is a NameVirtualHost
default server apps.library.newpaltz.edu (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost apps.library.newpaltz.edu (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost apps.library.newpaltz.edu (/etc/httpd/conf/httpd-le-ssl.conf:2)

Yeah, you have the same domain name handled by two different config files. Only one will be used (ssl.conf by the sounds of it).

The httpd-le-ssl.conf was made by Certbot based on your httpd.conf file.

I think the problem may be that your httpd.conf file is in /conf/ folder whereas the older ssl.conf file is in /conf.d/

Certbot may have created the new httpd-le-ssl.conf in the same folder as the http (port 80) one and didn't see the one for https (port 443) in conf.d

I'm not exactly sure the best way to sort out this mix and I don't have time to work up a test case for it. At least this might help explain what is happening


If I move the ssl.conf is there a repair-install or reinstall that might work?

" requests to /.well-known/acme-challenge/ get served from a directory within /var/lib/letsencrypt/ ."
If you can tell me what folder inside /var/lib/letsencrypt/ is the folder that holds the challenge file I will make a permanent link to that folder in my server config.

That's not needed or helpful. The Apache authenticator handles that automatically. _az, a Certbot developer, already described how that worked earlier.


Indeed, if you're using --apache, you can't make it not make this change to your configuration automatically, or not remove the change automatically afterwards!

(It might get confused about how to make that change correctly if there are multiple VirtualHosts that appear to cover the same name.)

If you want

  • to make --apache work: make sure the VirtualHost configuration is correct and that each one covers a unique name or set of names
  • to see what --apache did to your configuration in the course of satisfying the certificate authority's challenge: add the --debug-challenges option
  • to actually manually map a directory as the existing static content webroot (and be able to see /.well-known/acme-challenge on your disk on an ongoing basis): use --webroot instead of --apache (then you'll have to manually install the certificate afterward)
  • to make Certbot use a static content webroot location to request the certificate, but still attempt to install the certificate for you afterward: use -a webroot -i apache (splitting the authentication and installation functionality between two different Certbot plug-ins).

Thanks for all your help, it is great to see people respond quickly.
So the reason my server is not reading any of your modified SSL settings is because CertBot/Let’s Encrypt, could not read the VHOST in my SSL.conf file for some reason. Then it created a redundant SSL settings file with a redundant VHOST that the system is ignoring.
Perhaps we could fix the problem that prevented CertBot from reading the VHOST in my SSL.conf and reinstall it?

When I run certbot renew --dry-run --debug-challenges -v
I must assume the dry run is not testing the actual challenge file being available on web from server. I assume that because my server is ignoring the VHOST settings in your redundant ssl settings file.
Is the redundant SSL settings file or its include file the way certbot makes available the challenge files? ? That is my guess.

I looked at your previous instructions and I found the challenge folder and made it available from my httpd.conf with an alias that worked so I again ran “certbot renew --dry-run --debug-challenges -v” again and it did not find any issues or errors so I’m sticking with this fix for now.

1 Like

Certbot won't fix a webserver misconfiguration.
It works within your existing configuration and can add to it where needed.

Uninstalling/Reinstalling certbot won't change anything.

I'm happy that you are able to pass the --dry-run test.
You should review the certs [and names] covered, with:
certbot certificates
Ensuring the there are no name overlaps, no unused certs, no expired/unrenewing certs, and that all certs are being properly used by your web server.
If anything looks out-of-place or simply doesn't make sense to you, feel free to post that output here for our review.


I still think this is the likely reason although I have not tested it yet. You could just migrate any unique settings in the ssl.conf file into the one Certbot created in the /conf/ folder. Then, move your ssl.conf to a completely different folder so Apache doesn't still see it. Restart Apache. Run certbot renew --dry-run to test renewal


It actually does test it, using the Let's Encrypt staging service instead of the real Let's Encrypt service. The staging service will also specify location and contents for a challenge file, and will then make a connection from the Internet to check these on your web server. However, the staging service can't issue a publicly-trusted certificate. It issues a non-publicly-trusted certificate for your site, which --dry-run then doesn't save to disk anywhere (because it normally wouldn't be useful to you in any way).


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.