Two domains, different results

Help
1

I’ve got two domains. Both are going to run under mailcow on the same destination. I have rules to allow certain port 80 urls (used for mail configuration), and block redirect everything else.

Domains are example.nz and otherexample.co.nz
Port 80 on the router is port forwarded to the caddy server on port 8480
Port 443 on the router is port forwarded to the caddy server on port 8443.

Here are the caddy rules for each:
example.nz

http://mail.example.nz:8480/.well-known/acme-challenge, http://autodiscover.example.nz:8480/autodiscover/autodiscover.xml, http://autoconfig.example.nz:8480/autoconfig {
    log stdout
    errors stdout
    rewrite {
        to /proxy1{uri}
    }
    proxy /proxy1 http://internal.server:8480 {
        without /proxy1
        transparent
    }
}
http://mail.example.nz:8480 {
    log stdout
    errors stdout
    redir / https://mail.example.nz{uri}
}


https://mail.example.nz:8443,  https://autodiscover.example.nz:8443, https://autoconfig.example.nz:8443 {
    tls letsencrypt@example.nz {
        dns cloudflare
    }

    log stdout
    errors stdout

And otherexample.co.nz

http://mail.otherexample.co.nz:8480/.well-known/acme-challenge, http://autodiscover.otherexample.co.nz:8480/autodiscover/autodiscover.xml, http://autoconfig.otherexample.co.nz:8480/autoconfig {
    log stdout
    errors stdout
    rewrite {
        to /proxy1{uri}
    }
    proxy /proxy1 http://internal.server:8480 {
        without /proxy1
        transparent
    }

}
http://mail.otherexample.co.nz:8480 {
    log stdout
    errors stdout
    redir / https://mail.otherexample.co.nz{uri}
}

https://mail.otherexample.co.nz:8443, https://autodiscover.otherexample.co.nz:8443, https://autoconfig.otherexample.co.nz:8443 {
    tls letsencrypt@example.nz {
        dns cloudflare
    }

    log stdout
    errors stdout
    redir / https://www.google.com 302

}

So otherexample works fine. If I curl http://autodiscover.otherexample.co.nz I get a 404 as that’s not mentioned in the caddy file and I see an entry in the caddy log. But if I curl http://autodiscover.example.nz, I get a 301 moved permanently, and no log entry.

Similar for http://autodiscover.otherexample.co.nz/autodiscover/autodiscover.xml, with this I get a 401 - which is the correct response and means there is a page there.

 Hostname was NOT found in DNS cache
*   Trying 104.27.155.175...
* Connected to autodiscover.otherexample.co.nz (104.27.155.175) port 80 (#0)
> GET /autodiscover/autodiscover.xml HTTP/1.1
> User-Agent: curl/7.38.0
> Host: autodiscover.otherexample.co.nz
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Date: Tue, 11 Feb 2020 19:57:06 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d43811683653dc4a9f436bd3114156caf1581451026; expires=Thu, 12-Mar-20 19:57:06 GMT; path=/; domain=.otherexample.co.nz; HttpOnly; SameSite=Lax
< Www-Authenticate: Basic realm="autodiscover.otherexample.co.nz"
< X-Frame-Options: SAMEORIGIN
< CF-Cache-Status: DYNAMIC
* Server cloudflare is not blacklisted
< Server: cloudflare
< CF-RAY: 5638e3d36c56fb8c-AKL
<
* Connection #0 to host autodiscover.otherexample.co.nz left intact

But http://autodiscover.example.nz/autodiscover/autodiscover.xml

* Hostname was NOT found in DNS cache
*   Trying 104.27.166.114...
* Connected to autodiscover.example.nz (104.27.166.114) port 80 (#0)
> GET /autodiscover/autodiscover.xml HTTP/1.1
> User-Agent: curl/7.38.0
> Host: autodiscover.example.nz
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Tue, 11 Feb 2020 19:58:00 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Tue, 11 Feb 2020 20:58:00 GMT
< Location: https://autodiscover.example.nz/autodiscover/autodiscover.xml
* Server cloudflare is not blacklisted
< Server: cloudflare
< CF-RAY: 5638e524581aeea2-AKL
<
* Connection #0 to host autodiscover.example.nz left intact

And no entry in the caddy log. It doesn’t look like caddy is picking up the http example.nz entries at all. And yet they both get exactly the same response on https://autodiscover - which is the redirect to google.

2

As an aside, as part of trying ot diagnose I added:
log stdout "{remote} - {user} [{when}] \"{method} {uri} {proto}\" {status} {size} {header}"

And then lost all logging that any entry that had that directive.

3

Figured it out. You can see if runs through cloud flare…otherexample.co.nz had the cloudflare setting force HTTPS off…example.nz has this setting turned on.

If I wanted these settings on, how could I reconfigure my caddy rules?
Do I need to just accept https://autoconfig.example.nz/autoconfig and proxy it?

1 Like
4

See: https://caddyserver.com/v1/docs/log

The syntax is actually log path file [format].

Caddy will be attempting to create logs in the literal file name {remote} - {user} [{when}] \"{method} {uri} {proto}\" {status} {size} {header} in the current working directory.

To be unambiguous, you have Cloudflare reverse proxying to your Caddy server and you have Cloudflare issuing downgrade redirects for otherexample.co.nz, but issuing HTTP->S upgrade redirects for example.nz?

If you want Cloudflare to reverse proxy to Caddy, the simplest solution is to have Cloudflare always contact your origin server over HTTPS, preferably valid, and have Caddy always serving HTTPS. This confines your scheme concerns to one place - Cloudflare’s edge - reducing the complexity of your setup.

1 Like
5

I did find something referring to that extra / (for path) and have it working now to stdout.

Yes that did seem to be the case.

rinse and repeat for the otherexample.co.nz domain.

6

This statement in particular is loaded with ambiguity.

  • Where will you force HTTPS (Cloudflare? Caddy? Somewhere else?)
    • If Cloudflare, which direction are you referring to (client-facing or origin-facing?)
      • If client-facing - i.e. enforcing client HTTPS usage at the Cloudflare layer - isn’t this what you said you’re doing currently?

The method you use here is purely down to your own personal preference of presentation. As long as it meets your goals here - which I assume are simply not to return any meaningful content - there’s no convention for what you should use and there’s no real method that provides any major benefit.

7

Cloudflare would force https.

My main issue that I found when writing the email in the first instance, was that one domain cloudflare was forcing HTTPS and in the other it was not.

8

Looks good, then. As long as you keep that between the clients and Cloudflare, Caddy shouldn’t need to know anything about it, so no special handling required for scheme at the Caddy layer. Just handle the URLs you want as you’ve outlined, reject any URLs you don’t want in any manner you like, and Caddy will keep on trucking.

9

Thanks for the replies.

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.