Directory name "/.well-known" seems to be reserved on OS X Server, making challenge verification impossible #1782

Open
bobtiki opened this Issue Dec 6, 2015 · 20 comments

Comments

Projects
None yet
@bobtiki

bobtiki commented Dec 6, 2015

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, on my OS X Server, while most 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.

In /Library/Server/Web/Config/apache2/httpd_webdavsharing.conf there is a RewriteCond rule that reserves /.well-known by the system for WebDAV, related to the Calendar and Wiki services.

Is there any way to resolve this conflict without affecting services? The letsencrypt client seems to be hard wired to look for the challenge answer at this path, but is it possible to configure letsencrypt to check an alternate path?

@schoen

This comment has been minimized.

Show comment
Hide comment
@schoen

schoen Dec 8, 2015

Contributor

@bobtiki, the reason that /.well-known is used is specifically that it is reserved by Internet standards for purposes whose meaning is predefined, so we deliberately use this path because it will be reserved by web server tools and not allow an arbitrary unprivileged user to create resources under it.

https://tools.ietf.org/html/rfc5785

So, to use this challenge type with these servers we probably need to change it in the OS or get the upstream OS to support registering additional handlers for particular /.well-known resources.

Contributor

schoen commented Dec 8, 2015

@bobtiki, the reason that /.well-known is used is specifically that it is reserved by Internet standards for purposes whose meaning is predefined, so we deliberately use this path because it will be reserved by web server tools and not allow an arbitrary unprivileged user to create resources under it.

https://tools.ietf.org/html/rfc5785

So, to use this challenge type with these servers we probably need to change it in the OS or get the upstream OS to support registering additional handlers for particular /.well-known resources.

@bobtiki

This comment has been minimized.

Show comment
Hide comment
@bobtiki

bobtiki Dec 8, 2015

@schoen Thanks for the reply. I guess this is a bit above my head, then. I use OS X Server at home because of its other features (caching upgrades, etc.), but trying to get it to act like other Apache web servers has been, in my experience, more frustrating than it's worth. Unless it's in the GUI, I've had little luck changing settings as desired, even when the conf files are modified as it seems that they should.

I suppose then this becomes a request for more fully-featured OS X Server support on letsencrypt's end, so that it can be automated.

bobtiki commented Dec 8, 2015

@schoen Thanks for the reply. I guess this is a bit above my head, then. I use OS X Server at home because of its other features (caching upgrades, etc.), but trying to get it to act like other Apache web servers has been, in my experience, more frustrating than it's worth. Unless it's in the GUI, I've had little luck changing settings as desired, even when the conf files are modified as it seems that they should.

I suppose then this becomes a request for more fully-featured OS X Server support on letsencrypt's end, so that it can be automated.

@bmw bmw added the area: macOS label Dec 10, 2015

@ncstdc

This comment has been minimized.

Show comment
Hide comment
@ncstdc

ncstdc Dec 11, 2015

Edit this file:

/Library/Server/Web/Config/Proxy/apache_serviceproxy.conf

and comment out these 2 lines

Include /Applications/Server.app/Contents/ServerRoot/Library/Server/Web/Config/ProxyServices/CalendarServer/Unsecured.conf

Include /Applications/Server.app/Contents/ServerRoot/Library/Server/Web/Config/ProxyServices/CalendarServer/Secured.conf

restart the web server and .well-known should start working

ncstdc commented Dec 11, 2015

Edit this file:

/Library/Server/Web/Config/Proxy/apache_serviceproxy.conf

and comment out these 2 lines

Include /Applications/Server.app/Contents/ServerRoot/Library/Server/Web/Config/ProxyServices/CalendarServer/Unsecured.conf

Include /Applications/Server.app/Contents/ServerRoot/Library/Server/Web/Config/ProxyServices/CalendarServer/Secured.conf

restart the web server and .well-known should start working

@Dafdafdaf

This comment has been minimized.

Show comment
Hide comment
@Dafdafdaf

Dafdafdaf Dec 25, 2015

@ncstdc Thanks. Unfortunately the fix doesn't seem to work. (Server 5.0.15, OS X 10.11.2.) Same symptoms as @bobtiki. Any idea?

@ncstdc Thanks. Unfortunately the fix doesn't seem to work. (Server 5.0.15, OS X 10.11.2.) Same symptoms as @bobtiki. Any idea?

@pde pde added the question label Dec 26, 2015

@pde pde added this to the 1.0.0 milestone Dec 26, 2015

@hrrrsn

This comment has been minimized.

Show comment
Hide comment
@hrrrsn

hrrrsn Jan 3, 2016

@Dafdafdaf You also need to comment out
RewriteCond %{REQUEST_URI} !^/.well-known/.*
from /Library/Server/Web/Config/apache2/httpd_webdavsharing.conf

hrrrsn commented Jan 3, 2016

@Dafdafdaf You also need to comment out
RewriteCond %{REQUEST_URI} !^/.well-known/.*
from /Library/Server/Web/Config/apache2/httpd_webdavsharing.conf

@Dafdafdaf

This comment has been minimized.

Show comment
Hide comment
@Dafdafdaf

Dafdafdaf Jan 3, 2016

@hrrrsn Thanks, but it does not work either. Mystery.

@hrrrsn Thanks, but it does not work either. Mystery.

@dreness

This comment has been minimized.

Show comment
Hide comment
@dreness

dreness Jan 23, 2016

Hmm, yes, me too. I've tried the above suggestions, but when I issue a GET for http:///.well-known/acme-challenge, service_proxy_error.log gets:

[Sat Jan 23 14:08:53.308033 2016] [proxy:debug] [pid 25638] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (localhost)
[Sat Jan 23 14:08:53.308046 2016] [proxy:debug] [pid 25638] proxy_util.c(2199): [client 73.202.84.81:38361] AH00944: connecting http://localhost/.well-known/acme-challenge to localhost:80
[Sat Jan 23 14:08:53.308084 2016] [proxy:debug] [pid 25638] proxy_util.c(2235): [client 73.202.84.81:38361] AH02545: http: has determined UDS as /var/run/caldavd_requests/unsecured.sock
[Sat Jan 23 14:08:53.308298 2016] [proxy:debug] [pid 25638] proxy_util.c(2408): [client 73.202.84.81:38361] AH00947: connected /.well-known/acme-challenge to httpd-UDS:0
[Sat Jan 23 14:08:53.308559 2016] [proxy:error] [pid 25638] (2)No such file or directory: AH02454: HTTP: attempt to connect to Unix domain socket /var/run/caldavd_requests/unsecured.sock (localhost) failed

I think the clue is "http: has determined UDS as /var/run/caldavd_requests/unsecured.sock". caldavd is associated with the calendar & contacts service. For some reason, this request is being routed by the reverse proxy (aka 'service proxy) to the unix domain socket (UDS) belonging to the calendar & contacts service, which in my case is disabled. The reverse proxy backend connection fails, causing the client's request to the proxy to fail with 503:

<server> "<server>" <ip> - - [23/Jan/2016:14:18:48 -0800] "GET /.well-known/acme-challenge HTTP/1.1" 503 1585 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/601.4.4 (KHTML, like Gecko) Version/9.0.3 Safari/601.4.4"

The custom error page /customerror/websitesoff403.html is used for this failure, even if your websites are actually enabled. Perhaps the config logic assumes that if a backend connection fails, it's because the backend service is disabled.

Ultimately I think the problem is whatever config is causing the ".well-known" request to be routed to the calendar & contacts backend instead of one of the apache2 sites configured in /Library/Server/Web/Config/apache2/sites

dreness commented Jan 23, 2016

Hmm, yes, me too. I've tried the above suggestions, but when I issue a GET for http:///.well-known/acme-challenge, service_proxy_error.log gets:

[Sat Jan 23 14:08:53.308033 2016] [proxy:debug] [pid 25638] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (localhost)
[Sat Jan 23 14:08:53.308046 2016] [proxy:debug] [pid 25638] proxy_util.c(2199): [client 73.202.84.81:38361] AH00944: connecting http://localhost/.well-known/acme-challenge to localhost:80
[Sat Jan 23 14:08:53.308084 2016] [proxy:debug] [pid 25638] proxy_util.c(2235): [client 73.202.84.81:38361] AH02545: http: has determined UDS as /var/run/caldavd_requests/unsecured.sock
[Sat Jan 23 14:08:53.308298 2016] [proxy:debug] [pid 25638] proxy_util.c(2408): [client 73.202.84.81:38361] AH00947: connected /.well-known/acme-challenge to httpd-UDS:0
[Sat Jan 23 14:08:53.308559 2016] [proxy:error] [pid 25638] (2)No such file or directory: AH02454: HTTP: attempt to connect to Unix domain socket /var/run/caldavd_requests/unsecured.sock (localhost) failed

I think the clue is "http: has determined UDS as /var/run/caldavd_requests/unsecured.sock". caldavd is associated with the calendar & contacts service. For some reason, this request is being routed by the reverse proxy (aka 'service proxy) to the unix domain socket (UDS) belonging to the calendar & contacts service, which in my case is disabled. The reverse proxy backend connection fails, causing the client's request to the proxy to fail with 503:

<server> "<server>" <ip> - - [23/Jan/2016:14:18:48 -0800] "GET /.well-known/acme-challenge HTTP/1.1" 503 1585 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/601.4.4 (KHTML, like Gecko) Version/9.0.3 Safari/601.4.4"

The custom error page /customerror/websitesoff403.html is used for this failure, even if your websites are actually enabled. Perhaps the config logic assumes that if a backend connection fails, it's because the backend service is disabled.

Ultimately I think the problem is whatever config is causing the ".well-known" request to be routed to the calendar & contacts backend instead of one of the apache2 sites configured in /Library/Server/Web/Config/apache2/sites

@dreness

This comment has been minimized.

Show comment
Hide comment
@dreness

dreness Jan 24, 2016

Got it! The missing piece is to restart the service proxy after making the config changes suggested by @ncstdc, which I typically combine with a restart of the 'websites' service for good measure:

sudo serviceproxyctl restart
sudo apachectl restart

Looking at the config file that is now disabled (Config/ProxyServices/CalendarServer/Unsecured.conf), the very first line is what's grabbing /.well-known:

ProxyPass /.well-known unix:/var/run/caldavd_requests/unsecured.sock|http://localhost/.well-known

Taking another look at apache_serviceproxy.conf, I am suspicious about the presence of:

 #  com.apple.webapp.contactsserver is enabled
 #  com.apple.webapp.calendarserver is enabled
    RequestHeader set x-apple-service-webcalssl-enabled true

right above

    Include /Applications/Server.app/Contents/ServerRoot/Library/Server/Web/Config/ProxyServices/CalendarServer/Unsecured.conf

Neither the calendar nor contacts services are enabled, so I'm guessing this config shouldn't be here.
Here's some example 'acmetool status' output after successfully obtaining some certs:

andre@example [~] % acmetool status
Settings:
  ACME_STATE_DIR: /opt/brew/var/lib/acmetool
  ACME_HOOKS_DIR: /opt/brew/Cellar/acmetool/0.0.34_1/lib/hooks
  Default directory URL: https://acme-v01.api.letsencrypt.org/directory
  Preferred key type: rsa-2048
  Additional webroots:
    /Library/Server/Web/Data/Sites/Default/.well-known/acme-challenge

Available accounts:
  Account(acme-v01.api.letsencrypt.org%2fdirectory/<narf>)

Target(example.com,what.example.com,how.example.com,when.example.com;https://acme-v01.api.letsencrypt.org/directory;0):
  best: Certificate(<splank>)

Finally, import your new certs under /opt/brew/var/lib/acmetool/certs using Server; drag the cert, chain, and private key files into the 'import a certificate identity' sheet, as shown in this video: https://dreness.com/bits/tech/cert-import.mp4

dreness commented Jan 24, 2016

Got it! The missing piece is to restart the service proxy after making the config changes suggested by @ncstdc, which I typically combine with a restart of the 'websites' service for good measure:

sudo serviceproxyctl restart
sudo apachectl restart

Looking at the config file that is now disabled (Config/ProxyServices/CalendarServer/Unsecured.conf), the very first line is what's grabbing /.well-known:

ProxyPass /.well-known unix:/var/run/caldavd_requests/unsecured.sock|http://localhost/.well-known

Taking another look at apache_serviceproxy.conf, I am suspicious about the presence of:

 #  com.apple.webapp.contactsserver is enabled
 #  com.apple.webapp.calendarserver is enabled
    RequestHeader set x-apple-service-webcalssl-enabled true

right above

    Include /Applications/Server.app/Contents/ServerRoot/Library/Server/Web/Config/ProxyServices/CalendarServer/Unsecured.conf

Neither the calendar nor contacts services are enabled, so I'm guessing this config shouldn't be here.
Here's some example 'acmetool status' output after successfully obtaining some certs:

andre@example [~] % acmetool status
Settings:
  ACME_STATE_DIR: /opt/brew/var/lib/acmetool
  ACME_HOOKS_DIR: /opt/brew/Cellar/acmetool/0.0.34_1/lib/hooks
  Default directory URL: https://acme-v01.api.letsencrypt.org/directory
  Preferred key type: rsa-2048
  Additional webroots:
    /Library/Server/Web/Data/Sites/Default/.well-known/acme-challenge

Available accounts:
  Account(acme-v01.api.letsencrypt.org%2fdirectory/<narf>)

Target(example.com,what.example.com,how.example.com,when.example.com;https://acme-v01.api.letsencrypt.org/directory;0):
  best: Certificate(<splank>)

Finally, import your new certs under /opt/brew/var/lib/acmetool/certs using Server; drag the cert, chain, and private key files into the 'import a certificate identity' sheet, as shown in this video: https://dreness.com/bits/tech/cert-import.mp4

@Dafdafdaf

This comment has been minimized.

Show comment
Hide comment
@Dafdafdaf

Dafdafdaf Jan 26, 2016

@dreness Thanks, works like a charm now!

I hope some future Let's Encrypt client for OS X will take care of all of this.

@dreness Thanks, works like a charm now!

I hope some future Let's Encrypt client for OS X will take care of all of this.

@cedwardsmedia

This comment has been minimized.

Show comment
Hide comment
@cedwardsmedia

cedwardsmedia Mar 28, 2016

@Dafdafdaf while it's possible this may be automated one day, it's unlikely for two main reasons. As already pointed out, Apple really needs to provide a means of handing .well-known a bit better. Secondly, while OS X Server is frequently used by businesses and IT departments in-house, I have never encountered an OS X Server in the wild on the internet hosting any website unless it was someone's home server, as you've referenced in your scenario.

Who knows? Stranger things have happened in this world, but I wouldn't hold my breath on this being automated on OS X Server any time in the future unless Apple makes the move themselves.

@Dafdafdaf while it's possible this may be automated one day, it's unlikely for two main reasons. As already pointed out, Apple really needs to provide a means of handing .well-known a bit better. Secondly, while OS X Server is frequently used by businesses and IT departments in-house, I have never encountered an OS X Server in the wild on the internet hosting any website unless it was someone's home server, as you've referenced in your scenario.

Who knows? Stranger things have happened in this world, but I wouldn't hold my breath on this being automated on OS X Server any time in the future unless Apple makes the move themselves.

@cyrilpic

This comment has been minimized.

Show comment
Hide comment
@cyrilpic

cyrilpic Mar 30, 2016

For custom domains (i.e. not the domain linked to the server, but some additional domain you have added as a web service) this problem should be fixed in the Server 5.1 app.

For custom domains (i.e. not the domain linked to the server, but some additional domain you have added as a web service) this problem should be fixed in the Server 5.1 app.

@toco

This comment has been minimized.

Show comment
Hide comment
@toco

toco Aug 30, 2016

I was able to fix the problem on Mac OS X 10.9.5 with Server 3.2.2 without modifying auto generated configuration files.

Create a web app configuration that disables a reverse proxy for /.well-known/acme-challenge and save it as /Library/Server/Web/Config/apache2/webapps/org.letsencrypt.acme.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<!-- save as /Library/Server/Web/Config/apache2/webapps/org.letsencrypt.acme.plist -->
<!-- See man pages for webapp.plist(5) and webappctl(8) for information about web app configuration -->
<plist version="1.0">
<dict> 
    <key>name</key>
    <string>org.letsencrypt.acme</string>
    <key>displayName</key>      <!-- Name shown in Server app -->
    <string>Let's Encrypt ACME</string>
    <key>proxies</key>      <!-- ProxyPass/ProxyPassReverse directives are activated when webapp is started -->
    <dict>
        <key>/.well-known/acme-challenge</key>      <!-- Sets up a reverse proxy -->
        <dict>
            <key>path</key>
            <string>/.well-known/acme-challenge</string>
            <key>urls</key>
            <array/> <!-- Disable Proxy --> 
        </dict>
    </dict>
    <key>sslPolicy</key>    <!-- Determines webapp SSL behavior -->
    <integer>0</integer>    <!-- 0: default, UseSSLWhenEnabled -->
            <!-- 1: UseSSLAlways -->
            <!-- 2: UseSSLOnlyWhenCertificateIsTrustable -->
            <!-- 3: UseSSLNever -->
            <!-- 4: UseSSLAndNonSSL -->
</dict>
</plist>

Start the "web app" with sudo webappctl start org.letsencrypt.acme.
Check that ProxyPass /.well-known/acme-challenge ! is before the the other ProxyPass lines in your config (/Library/Server/Web/Config/apache2/sites/0000_any_443_.conf).

If that's not the case you might need to restart the calendar and addressbook server to get the order right.

sudo serveradmin stop calendar
sudo serveradmin stop addressbook
sudo serveradmin start addressbook
sudo serveradmin start calendar

Now you should be able to use letsencrypt with automatic ACME challenges.
Note: The above file paths might be different on newer systems.

toco commented Aug 30, 2016

I was able to fix the problem on Mac OS X 10.9.5 with Server 3.2.2 without modifying auto generated configuration files.

Create a web app configuration that disables a reverse proxy for /.well-known/acme-challenge and save it as /Library/Server/Web/Config/apache2/webapps/org.letsencrypt.acme.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<!-- save as /Library/Server/Web/Config/apache2/webapps/org.letsencrypt.acme.plist -->
<!-- See man pages for webapp.plist(5) and webappctl(8) for information about web app configuration -->
<plist version="1.0">
<dict> 
    <key>name</key>
    <string>org.letsencrypt.acme</string>
    <key>displayName</key>      <!-- Name shown in Server app -->
    <string>Let's Encrypt ACME</string>
    <key>proxies</key>      <!-- ProxyPass/ProxyPassReverse directives are activated when webapp is started -->
    <dict>
        <key>/.well-known/acme-challenge</key>      <!-- Sets up a reverse proxy -->
        <dict>
            <key>path</key>
            <string>/.well-known/acme-challenge</string>
            <key>urls</key>
            <array/> <!-- Disable Proxy --> 
        </dict>
    </dict>
    <key>sslPolicy</key>    <!-- Determines webapp SSL behavior -->
    <integer>0</integer>    <!-- 0: default, UseSSLWhenEnabled -->
            <!-- 1: UseSSLAlways -->
            <!-- 2: UseSSLOnlyWhenCertificateIsTrustable -->
            <!-- 3: UseSSLNever -->
            <!-- 4: UseSSLAndNonSSL -->
</dict>
</plist>

Start the "web app" with sudo webappctl start org.letsencrypt.acme.
Check that ProxyPass /.well-known/acme-challenge ! is before the the other ProxyPass lines in your config (/Library/Server/Web/Config/apache2/sites/0000_any_443_.conf).

If that's not the case you might need to restart the calendar and addressbook server to get the order right.

sudo serveradmin stop calendar
sudo serveradmin stop addressbook
sudo serveradmin start addressbook
sudo serveradmin start calendar

Now you should be able to use letsencrypt with automatic ACME challenges.
Note: The above file paths might be different on newer systems.

@olsonpm

This comment has been minimized.

Show comment
Hide comment
@olsonpm

olsonpm Oct 29, 2016

the reason that /.well-known is used is specifically that it is reserved by Internet standards for purposes whose meaning is predefined, so we deliberately use this path because it will be reserved by web server tools and not allow an arbitrary unprivileged user to create resources under it.

It's odd the spec chose '.well-known' to be a hidden directory, considering it seems to be intended for public access. I'd say the spec messed that one up, and letsencrypt should likewise have avoided using it because of the obvious ensuing problems.

olsonpm commented Oct 29, 2016

the reason that /.well-known is used is specifically that it is reserved by Internet standards for purposes whose meaning is predefined, so we deliberately use this path because it will be reserved by web server tools and not allow an arbitrary unprivileged user to create resources under it.

It's odd the spec chose '.well-known' to be a hidden directory, considering it seems to be intended for public access. I'd say the spec messed that one up, and letsencrypt should likewise have avoided using it because of the obvious ensuing problems.

@inventari

This comment has been minimized.

Show comment
Hide comment
@inventari

inventari Nov 3, 2016

Thank you @toco.
@olsonpm I believe the reason that the spec uses the .well-known directory, is because you would need to be admin on a system to allow access to it.

Thank you @toco.
@olsonpm I believe the reason that the spec uses the .well-known directory, is because you would need to be admin on a system to allow access to it.

@olsonpm

This comment has been minimized.

Show comment
Hide comment
@olsonpm

olsonpm Nov 3, 2016

@inventari - still seems like a functional oversight considering the spec was written after the convention of web servers hiding 'dot' files.

olsonpm commented Nov 3, 2016

@inventari - still seems like a functional oversight considering the spec was written after the convention of web servers hiding 'dot' files.

@cpu

This comment has been minimized.

Show comment
Hide comment
@cpu

cpu Nov 4, 2016

Member

@olsonpm this is a broader trend within IETF RFCs that the CABF and the ACME specification are respecting. See RFC 5785 and the directory of .well-known reservations.

I agree that the usage of a leading . in the well known directory can negatively interact with existing "hidden folder" webserver configurations but unfortunately its not a problem that can be solved by Certbot or Let's Encrypt.

Member

cpu commented Nov 4, 2016

@olsonpm this is a broader trend within IETF RFCs that the CABF and the ACME specification are respecting. See RFC 5785 and the directory of .well-known reservations.

I agree that the usage of a leading . in the well known directory can negatively interact with existing "hidden folder" webserver configurations but unfortunately its not a problem that can be solved by Certbot or Let's Encrypt.

@olsonpm

This comment has been minimized.

Show comment
Hide comment
@olsonpm

olsonpm Nov 4, 2016

@cpu - Yeah I browsed the rfc and understand how 'minting' a new name ensures no conflicting directories. I still don't feel that is a reasonable trade off for the mass number of server reconfigurations required just to get free ssl.

My point is it's not Let's Encrypt's problem to fix, it's their problem to avoid altogether.

olsonpm commented Nov 4, 2016

@cpu - Yeah I browsed the rfc and understand how 'minting' a new name ensures no conflicting directories. I still don't feel that is a reasonable trade off for the mass number of server reconfigurations required just to get free ssl.

My point is it's not Let's Encrypt's problem to fix, it's their problem to avoid altogether.

@cpu

This comment has been minimized.

Show comment
Hide comment
@cpu

cpu Nov 4, 2016

Member

@olsonpm we can't avoid it. We have to follow the CABF's baseline requirements, which since ballot 182 have specified the usage of .well-known under the rules for domain validation, "3.2.2.4.6 Agreed-Upon Change to Website". The decision to change would have to start at the CABF or higher before we could change the ACME HTTP validation method to use anything else.

Member

cpu commented Nov 4, 2016

@olsonpm we can't avoid it. We have to follow the CABF's baseline requirements, which since ballot 182 have specified the usage of .well-known under the rules for domain validation, "3.2.2.4.6 Agreed-Upon Change to Website". The decision to change would have to start at the CABF or higher before we could change the ACME HTTP validation method to use anything else.

@olsonpm

This comment has been minimized.

Show comment
Hide comment
@olsonpm

olsonpm Nov 4, 2016

Interesting. Thanks so much for those references. I have a lot to learn.

olsonpm commented Nov 4, 2016

Interesting. Thanks so much for those references. I have a lot to learn.

@cpu

This comment has been minimized.

Show comment
Hide comment
@cpu

cpu Nov 4, 2016

Member

@olsonpm you're very welcome. Hate to be the bearer of bad news, I know the real-world implications of these decisions mean a poor experience for some users, particularly those with OS X Servers :-#

Member

cpu commented Nov 4, 2016

@olsonpm you're very welcome. Hate to be the bearer of bad news, I know the real-world implications of these decisions mean a poor experience for some users, particularly those with OS X Servers :-#

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