Skip to content

Instantly share code, notes, and snippets.

@swizzlevixen

swizzlevixen/osx-server-well-known.markdown

Last active December 6, 2015 18:04
Show Gist options
  • Save swizzlevixen/606a66b0c4ce06dabf06 to your computer and use it in GitHub Desktop.
Save swizzlevixen/606a66b0c4ce06dabf06 to your computer and use it in GitHub Desktop.
Download ZIP
Trying to resolve a conflict with OS X Server and a web directory named "/.well-known" so I can authorize a letsencrypt.org certificate.
Raw
osx-server-well-known.markdown

I'm trying to figure out if OS X Server has, for some reason, reserved the directory name /.well-known, and if so, how to work around it, so that I can authenticate my server for requesting an SSL certificate with letsencrypt.org.

During the letsencrypt authentication process, I must put a challenge response on my server, at the URL path:

http://example.com/.well-known/acme-challenge/<challenge key>

However, while dot-hidden paths like /.the-directory are served just fine, I seem to have narrowed down that /.well-known, in specific, always returns a 503 error message, even while OS X Server's Web services are turned on and reponding otherwise normally:

Websites are turned off.
An administrator can turn them on using the Server application.

I thought I might be able to rewrite or redirect from /.well-known to a different directory on my server, but having tried both of those tacks via .htaccess overrides, as well as with the OS X Server GUI Aliases and Redirects settings, nothing I do will seem to make the server respond to an URL including /.well-known, despite being able to alias and redirect any other directory name that I could think of to test.

Is /.well-known reserved by the system for some reason, and is there any way to resolve this conflict? The letsencrypt client seems to be hard wired to look for the challenge answer at this path, but it's the one path that it seems I can't control on OS X Server.

Update: WebDAV

In Library/Server/Web/Config/apache2/httpd_webdavsharing.conf, there is this line:

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

…which seems to be overriding my attempts to grab that particular pattern. (There are also several other directory patterns here that surprised me, since I didn't know they were reserved.) None of the services I'm currently running seem to need WebDAV, so I'm not sure why these rules are still being loaded. I tried commenting out the line above, to no avail.

@danimal
Copy link

danimal commented Dec 6, 2015

I wonder if you can try unloading the WebDAV module in the config (well, if it's loaded) would keep that from impacting you. I don’t have OS X server handy to look at it right now though :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment