Is the webroot plugin's sub-directory consistent?


#1

So I’m hoping to try Let’s Encrypt out soon, and I think the webroot plugin is going to be the best method for me (assuming my computer will stop auto-correcting it to “webfoot” :stuck_out_tongue:).

Anyway, I’m trying to plan how I’ll set everything up, but I noticed that to use the webroot method I’ll need to allow access to hidden directories, which I take to mean that it will create a hidden directory from which to serve its verification file(s). What I’d like to know is whether the name of this sub-directory is consistent or controllable?

You see, my nginx server currently denies access to all hidden files, mostly just as a precautionary measure (I’m pretty sure I don’t actually have any), but I’d like to avoid disabling this rule if I can.

If webroot does use a consistent sub-directory name, or can be configured to do-so, then I can add an exception for that directory only, but if it’s random I guess I’ll just have to go ahead and disable the rule for hidden files/directories, though I’d prefer not to.


#2

As far as I know (and have seen), it’s always something in the form of: /.well-known/acme-challenge/alotofrandomgarbagebutnothiddenfile

So if you’ll allow .well-know, you’ll be allright I guess.


#3

It will always be /.well-known/acme-challenge/%token%, where %token% is a random base64url encoded token.


#4

check out Using the webroot domain verification method example you can do a specific location context match to allow .well-known directories. I do the same for me webroot implementation on Nginx Letsencrypt Webroot Authentication Tested on Beta invited/whitelisted domain