How to allow access "/.well-known/acme-challenge/*" in "public" directory

[essovius]

Hello, I'm trying to set up TLS in my self-hosted umami server. I couldn't figure out how to allow access on custom directories in "public" dir. Umami is currently installed on my Nginx Unit server as a proxy. I've already tried to allow it through Unit's configuration file by adding

"routes": [
                {
			"match": {
				"host": "umami.example.com"
			},
			"action": {
				"proxy": "http://127.0.0.1:4000"
                        }
		},
		{
			"match": {
				"uri": "/.well-known/acme-challenge/*"
			},

			"action": {
				"share": "/root/umami/public/"
			}
		}
]

But the certbot couldn't reach the "/.well-known/" dir. I also tried to create custom directory called "test" in public dir and put some images in there but I also couldn't reach these files via URL umami.example.com/test/test.png

Sorry if this is a super basic question. I am fairly new at nextjs applications and I wonder if I'm missing something, should I change something in umami's source codes to allow it?

I'd really appreciate your help. 🙏

[danielledeleo]

Hi essovius, happy to help you out here. Can you share the rest of your configuration, if there is more to it? Have you been following our Certbot guide?

I assume you're attempting to get a certificate for umami.example.com, correct? I believe the issue is that the first "match": { "host": "umami.example.com" }" block is matching the block that points to "/.well-known/acme-challenge/*". Try reversing the order of the blocks like this:

"routes": [
    {
        "match": {
            "uri": "/.well-known/acme-challenge/*"
        },
        "action": {
            "share": "/root/umami/public/"
        }
    },
    {
        "match": {
            "host": "umami.example.com"
        },
        "action": {
            "proxy": "http://127.0.0.1:4000"
        }
    }
]

The problem is that routes are matched in order, so if Let's Encrypt's servers are making a request to umami.example.com/.well-known/acme-challenge/, the host (umami.example.com) is matched first and the share action is ignored.

However, as shown in the guide I linked above you may want to separate your Certbot routes from your proxy routes. I can help you with that too.

[essovius]

Hi, danielledeleo! Thank you very much for your help! I was getting the 404 error earlier with my config, so basically it was ignored as you said. But after I changed it, now I'm getting 403 (forbidden) error when I tried to reach the file. I've double checked that the unit user has ownership on the directory and the files.

Currently I have two websites running on Nginx Unit, so I've tried to access the "test" file by putting it in the other website's (which is PHP) public directory and it worked with the current config. But it doesn't work if I put it in the "Umami"'s public directory. I'm guessing it's something to do with next.js' route settings.

Here's my current configuration looks like:

{
  "listeners": {
    "*:80": {
      "pass": "routes"
    },
    "*:443": {
      "pass": "routes",
      "tls": {
        "certificate": "certbot1"
      }
    }
  },
  "routes": [
    {
      "match": {
        "uri": "/.well-known/acme-challenge/*"
      },
      "action": {
        "share": "/root/umami/public$uri"
      }
    },
    {
      "match": {
        "host": [
          "foo.net",
          "www.foo.net"
        ],
        "uri": "!/index.php"
      },
      "action": {
        "share": "/www/foo/public$uri",
        "fallback": {
          "pass": "applications/foo"
        }
      }
    },
    {
      "match": {
        "host": "stats.example.com"
      },
      "action": {
        "proxy": "http://127.0.0.1:4000"
      }
    }
  ],
  "applications": {
    "foo": {
      "type": "php",
      "processes": {
        "max": 10,
        "spare": 5,
        "idle_timeout": 20
      },
      "root": "/www/foo/public/",
      "working_directory": "/www/foo/",
      "options": {
        "file": ":/etc/php83/php.ini",
        "admin": {
          "opcache.preload": "/www/foo/preload.php"
        }
      },
      "script": "index.php"
    }
  }
}

I can reach the file if I change "share": "/root/umami/public$uri" to "share": "/www/foo/public$uri" which is my PHP application's public directory. But I want to access it in Umami's public directory.

[ac000]

Does adding $uri to your share path make it work? I.e

"action": {
    "share": "/root/umami/public$uri"
}

See here, the way share works was changed in 1.26.0

[essovius]

Hi ac000, please see my previous reply here: #1216 (reply in thread)

[ac000]

Does Unit have access to /root/umami/public? What user is it running as? unit will need at least execute (x) permissions for other on the directories...

[essovius]

unit user has access, ownership and x pemissions to "/root/umami/public" and files.

[lcrilly]

Might be worth enabling router diagnostic logging to see exactly what's going on, especially with the mix of host and uri route matching.

$ echo '{"http": {"log_route": true}}' | unitc /config/settings

[essovius]

2024/04/10 20:14:05 [notice] 4260#4267 *6 http request line "GET /test/test.txt HTTP/1.1"
2024/04/10 20:14:05 [notice] 4260#4267 *6 "routes/0" selected
2024/04/10 20:14:05 [error] 4260#4267 *6 opening "/root/umami/public/test/test.txt" failed (13: Permission denied)
2024/04/10 20:14:06 [notice] 4260#4267 *6 http request line "GET /favicon.ico HTTP/1.1"
2024/04/10 20:14:06 [info] 4260#4267 *6 "routes/0" discarded
2024/04/10 20:14:06 [info] 4260#4267 *6 "routes/1" discarded
2024/04/10 20:14:06 [notice] 4260#4267 *6 "routes/2" selected

[ac000]

2024/04/10 20:14:05 [error] 4260#4267 *6 opening "/root/umami/public/test/test.txt" failed (13: Permission denied)

Check the perms on the /root, /root/umami & /root/umami/public/test directories and the file itself...

[essovius]

I can already access the files that came with Umami (favicon.ico, robots.txt etc.. ) via url which is in the same place with the test file that I placed. I wonder why I can access those files but not the test file i put in. I have checked the permissions several times. It has the same permissions and user (unit) as the files that come with umami and I have not made any changes to them. Maybe the problem is in the route settings of umami?

Also giving unit privileges to whole /root folder is safe? Could that be the problem? Maybe I should completely move umami from /root to another folder like /www, I'm not sure if that can cause the issue.

[ac000]

I can already access the files that came with Umami (favicon.ico, robots.txt etc.. ) via url which is in the same place with the test file that I placed. I wonder why I can access those files but not the test file i put in. I have checked the permissions several times. It has the same permissions and user (unit) as the files that come with umami and I have not made any changes to them. Maybe the problem is in the route settings of umami?

The error is pretty clear...

2024/04/10 20:14:05 [error] 4260#4267 *6 opening "/root/umami/public/test/test.txt" failed (13: Permission denied)

That's from the unit log you posted.

Please post the output of

# ls -ld /root /root/umami /root/umami/public /root/umami/public/test
# ls -l /root/umami/public/test/test.txt

Also giving unit privileges to whole /root folder is safe? Could that be the problem? Maybe I should completely move umami from /root to another folder like /www, I'm not sure if that can cause the issue.

I would say using /root at all for this is a weird thing to do...

[essovius]

I would say using /root at all for this is a weird thing to do...

Moving umami folder to /www fixed the problem. Thank you for your help!

[ac000]

It could also be being blocked by the likes of selinux or apparmour... what distribution you using? I'm assuming some flavour of Linux. But let's see what ls(1) says first...