Using caddy to serve mta-sts files

Help
1

1. My Caddy version (caddy version):

v2.0.0-rc.3 h1:z2H/QnaRscip6aZJxwTbghu3zhC88Vo8l/K57WUce4Q=

2. How I run Caddy:

a. System environment:

Fedora 31

b. Command:

caddy run -resume

c. Service/unit/compose file:

None

d. My complete Caddyfile or JSON config:

            {
              "handle": [
                {
                  "handler": "subroute",
                  "routes": [
                    {
                      "handle": [
                        {
                          "handler": "headers",
                          "response": {
                            "set": {
                              "Strict-Transport-Security": [
                                "max-age=63072000; includeSubDomains; preload"
                              ]
                            }
                          }
                        },
                        {
                          "encodings": {
                            "gzip": {},
                            "zstd": {}
                          },
                          "handler": "encode"
                        },
                        {
                          "handler": "file_server",
                          "root": "/var/www/mta-sts"
                        }
                      ],
                      "match": [
                        {
                          "path": [
                            "/.well-known"
                          ]
                        }
                      ]
                    }
                  ]
                }
              ],
              "match": [
                {
                  "host": [
                    "mta-sts.meeple.ninja"
                  ]
                }
              ],

3. The problem I’m having:

I am trying to serve a /.well-known/mta-sts.txt file (See Introducing MTA Strict Transport Security (MTA-STS) | Hardenize Blog for an explanation of MTA-STS) for my various smtp serving domains. I want to serve NOTHING but the mta-sts.txt file on the url https://mta-sts.meeple.ninja/.well-known/mta-sts.txt. Also, the inability of Caddyfiles to handle logging in caddy v2 frustrated me, so now I am trying to learn it’s JSON config structure. Any assistance would be awesome.

4. Error messages and/or full log output:

{
  "level": "info",
  "ts": 1587626077.1194618,
  "logger": "http.log.access.mta-sts",
  "msg": "handled request",
  "request": {
    "method": "GET",
    "uri": "/.well-known/mta-sts.txt",
    "proto": "HTTP/2.0",
    "remote_addr": "[2604:a880:1:20::121:2001]:48194",
    "host": "mta-sts.meeple.ninja",
    "headers": {
      "User-Agent": [
        "curl/7.66.0"
      ],
      "Accept": [
        "*/*"
      ]
    },
    "tls": {
      "resumed": false,
      "version": 772,
      "ciphersuite": 4865,
      "proto": "h2",
      "proto_mutual": true,
      "server_name": "mta-sts.meeple.ninja"
    }
  },
  "common_log": "2604:a880:1:20::121:2001 - - [23/Apr/2020:00:14:37 -0700] \"GET /.well-known/mta-sts.txt HTTP/2.0\" 0 0",
  "latency": 2.2032e-05,
  "size": 0,
  "status": 0,
  "resp_headers": {
    "Server": [
      "Caddy"
    ]
  }
}

5. What I already tried:

6. Links to relevant resources:

1 Like
2

In Caddy v2, path matchers are exact match, not prefix match.

I think you just need to change your matcher from:
"path": ["/.well-known"]

to:
"path": ["/.well-known/*"]

3

Have you seen the log directive?

1 Like
4

I have. And it is clunky and inexact. And the default logger was making a mess. Managing in JSON is much cleaner.

5

This isn’t much better. I get a 404 now. I know the file exists, and I had no issues serving it under Caddy v1 with a caddyfile

mta-sts.meeple.ninja {
  log /var/log/caddy/mta-sts.meeple.ninja.log

  root /var/www/mta-sts

  tls {
    alpn h2
  }

  header / { 
    Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
  }

  rewrite {
    r ^/\.well-known/mta-sts.txt$
    to /mta-sts.txt
  }
}

I really wanted to use the file_server directly with path matching using the /.well-known as root. instead of doing rewriting, but apparently I an not quite understanding how matcher & handler link together.

6

Ok, so even if you set your file_server root against a match that isn’t hostname part of URI, that part of the match URI is still respected. So I either need a re-write, or to place the file in .well-known in my root. This seems non-intuitive.

7

I note that in your v1 Caddyfile you rewrite to remove the /.well-known prefix - so I assume your file is located at /var/www/mta-sts/mta-sts.txt. As you note, yes, you will need to carry forward the v1 rewrite to v2 if you need to strip that prefix.

The matcher does not manipulate the request in any way. A path matcher is capable of matching any sections of a path, including globular matching, prefix or suffix matching. For Caddy to assume it should, in fact, alter the request with respect to a specified web root when serving files would be the counter-intuitive behaviour.

A matcher simply filters which requests are applicable to the associated handlers, they don’t necessarily link together any further than that.

4 Likes
8

thank you very much. I guess I will a rewrite to that handler for that match. thanks!

1 Like
9

Regarding logging in the Caddyfile, could you give some examples of what you’re trying that you’re finding clunky? It’s likely something we can improve but we need some usecases to target

10

The biggest one is I want to reduce logging level from INFO to WARN for default logs, and have them emitted directed to a file output in JSON. I can handle access logs in Caddyfile, but I can’t modify the default log.

11

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