.well-known folder location?

[jmunoz]

My domain is:
reverseproxy.mercurynetworks.net

I ran this command:
n/a

It produced this output:
n/a

My web server is (include version):
Server version: Apache/2.4.52 (Ubuntu)
Server built: 2023-05-03T20:02:51

The operating system my web server runs on is (include version):
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy

My hosting provider, if applicable, is:
AWS

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 2.7.1

I'm needing to upload some additional files to the /.well-known directory for third-party verification. Certbot appears to already be publishing to this directory. Can I just add my custom verification files to this directory? and if so, where is this directory at?
I searched
ls -a /var/www/html
but didn't see it listed in there.

[Osiris]

If it's empty, I believe Certbot deletes it again.

You can simply make it yourself if required.

[schoen]

Certbot only uses a persistent /.well-known directory at all if you're using the --webroot method. Otherwise (with --nginx, --apache, and --standalone methods) it creates a totally separate directory and serves content from there, or otherwise configures the web server to temporarily serve some static content at the appropriate location.

Other content that you put into /.well-known/acme-challenge in your regular webroot may be temporarily invisible when certbot --nginx or certbot --apache is actively satisfying a challenge from the certificate authority.

[rg305]

Hi @jmunoz, and welcome to the LE community forum

@jmunoz

I searched
ls -a /var/www/html
but didn't see it listed in there.

And you probably never will - given the use of --apache [for authentication].

What I would do:

• Start with the output of: sudo apachectl -t -D DUMP_VHOSTS
• ensure there are no name/port overlaps
• find the [one] file that serves the HTTP content for the desired FQDN
• look for the location applied specifically for the .well-known request
  [if none is defined, then use the DocumentRoot found in that vhost]
• using that root path, create any subfolder(s) and file(s) as needed

Then test access via something like [adjust accordingly]:
http://your-FQDN/.well-known/[path(s)/]file-you-made