path-based routing acl should before host acl

[heww]

Those days I test https://github.com/mesosphere/letsencrypt-dcos to generate SSL certs with marathon-lb.

I use https://raw.githubusercontent.com/mesosphere/letsencrypt-dcos/master/letsencrypt-dcos.json which only change the HAPROXY_0_VHOST to our hosts to deploy letsencrypt-dcos. HAPROXY_0_VHOST in my letsencrypt-dcos is chat.xxx.com,wekan.xxx.com,npm.xxx.com （xxx.com is our domain） .

Unlucky, generate certs failed with following errors

DOMAIN_ARGS:  -d chat.xxx.com -d wekan.xxx.com -d npm.xxx.com
DOMAIN_FIRST: chat.xxx.com
Running letsencrypt-auto to generate initial signed cert
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt --no-self-upgrade certonly --standalone --standalone-supported-challenges http-01 -d chat.xxx.com -d wekan.xxx.com -d npm.xxx.com --email admin@xxx.com --agree-tos --non-interactive --no-redirect --rsa-key-size 4096 --expand
IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: chat.xxx.com
   Type:   unauthorized
   Detail: Error parsing key authorization file: Invalid key
   authorization: 32 parts

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

At first, I bing those errors and doubt our dns nameservers which using skydns may not support letsencrypt. So we switch our dns nameservers to CloudXNS which support letsencrypt. It failed again with above errors .

Then, I run /root/.local/share/letsencrypt/bin/letsencrypt --no-self-upgrade certonly --standalone --standalone-supported-challenges http-01 -d chat.xxx.com -d wekan.xxx.com -d npm.xxx.com --email admin@xxx.com --agree-tos --non-interactive --no-redirect --rsa-key-size 4096 --expand manual in a container (at this point letsencrypt-dcos is still running start stop start in marathon one by one) and of course failed. I found some different with above errors. chat.xxx.com still unauthorized , npm.xxx.com got the acme-challenge.

Maybe our npm.xxx.com is fine, so I deploy letsencrypt-dcos app only with npm.xxx.com HAPROXY_0_VHOST , aha, generate SSL certs succeed. At this point, I still doubt may there is something wrong with chat.xxx.com dns record.

Yesterday, suddenly I was inspired, maybe chat.xxx.com/.well-known/acme-challenge not proxy to letsencrypt-dcos app but still to chat because chat acl rule in marathon-lb haproxy.cfg is before of letsencrypt-dcos.

Today, I change letsencrypt-dcos app Id to aaletsencrypt-dcos so that the acl rules of aaletsencrypt-dcos are before others. Then SSL certs generate succeed.

DOMAIN_ARGS:  -d npm.xxx.com -d chat.xxx.com
DOMAIN_FIRST: npm.xxx.com
Running letsencrypt-auto to generate initial signed cert
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt --no-self-upgrade certonly --standalone --standalone-supported-challenges http-01 -d npm.xxx.com -d chat.xxx.com --email admin@xxx.com --agree-tos --non-interactive --no-redirect --rsa-key-size 4096 --expand
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/npm.xxx.com/fullchain.pem. Your cert
   will expire on 2016-07-13. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Posting new cert to marathon-lb
Retrieving current marathon-lb cert
Comparing old cert to new cert
Deploying marathon-lb with new cert
Waiting for deployment to complete

[brndnmtthws]

Yep, this makes sense.

[brndnmtthws]

If you can test out the mesosphere/marathon-lb:backend-acl-weights image, that'd be great.

[heww]

I tested the mesosphere/marathon-lb:backend-acl-weights image, and it works ok.