Caddyfile: subject does not qualify for certificate with http://*

[0az]

Caddy v2.3.0 errors on the previously-valid http-only wildcard site http://*, which is a regression from v2.2.0 behavior.

Example Caddyfile

http://* {
	respond "Hello, world!"
}

(I might get around to figuring out how git bisect run works in the morning: should be fun.)

[francislavoie]

Wildcard characters only match a single domain segment. Just remove the * to match all domains.

[0az]

Wildcard characters only match a single domain segment. Just remove the * to match all domains.

I'm 50% sure that the wildcard matching single segments was intentional, since this was deployed with a collection of HTTPS sites that I wanted auto-HTTPS for.

# 1.Caddyfile
{
	# Just for local replication
	local_certs
}

http://* {
	respond "Hello, world!"
}

localhost.internal {
	respond "Hello, https!"
}

If you drop the wildcard, in v2.2.0, it catches http://localhost.internal, and does not force the wildcard. In v2.3.0, it errors with

run: loading initial config: loading new config: loading tls app module: tls: invalid configuration: automation policy 1 is the second policy that acts as default/catch-all, but will never be used

Poking at the adapted JSON, it looks like there's two repeated blocks:

caddy adapt output of 1.Caddyfile, with wildcard removed.

{
  "apps": {
    "http": {
      "servers": {
        "srv0": {
          "listen": [
            ":443"
          ],
          "routes": [
            {
              "match": [
                {
                  "host": [
                    "localhost.internal"
                  ]
                }
              ],
              "handle": [
                {
                  "handler": "subroute",
                  "routes": [
                    {
                      "handle": [
                        {
                          "body": "Hello, https!",
                          "handler": "static_response"
                        }
                      ]
                    }
                  ]
                }
              ],
              "terminal": true
            }
          ]
        },
        "srv1": {
          "listen": [
            ":80"
          ],
          "routes": [
            {
              "handle": [
                {
                  "body": "Hello, world!",
                  "handler": "static_response"
                }
              ]
            }
          ]
        }
      }
    },
    "tls": {
      "automation": {
        "policies": [
          {
            "issuers": [
              {
                "module": "internal"
              }
            ]
          },
          {
            "issuers": [
              {
                "module": "internal"
              }
            ]
          }
        ]
      }
    }
  }
}

This seems like a different bug, though.

[francislavoie]

I'm 50% sure that the wildcard matching single segments was intentional, since this was deployed with a collection of HTTPS sites that I wanted auto-HTTPS for.

To clarify, cause I'm not certain we're on the same page on this, "single-segment" means a domain like "localhost", but not "localhost.internal", because that's two segments (separated by .). This is also known as "labels" (Caddy uses that terminology in the docs for the placeholders as well, I probably should have used that word instead)

But anyways, @mholt will need to take a look 😄

[0az]

To clarify, cause I'm not certain we're on the same page on this, "single-segment" means a domain like "localhost", but not "localhost.internal", because that's two segments (separated by .). This is also known as "labels" (Caddy uses that terminology in the docs for the placeholders as well, I probably should have used that word instead)

Yeah, I'm aware of that, and I abuse that to ensure that only single-segment sites (localhost, and a couple others) have that wildcard block applied, and not anything public facing. localhost.internal is a poorly chosen stand-in for a """production""" domain.

[mholt]

@0az Thanks for the report, I'm looking into this.

Meanwhile:

Does this commit fix the repeated automation policies bug for you? It's recent, you'll have to get the latest build artifacts from our CI or use xcaddy on the latest commit/master: 7846bc1

[mholt]

@0az I think the commit I just pushed, d68cff8, is a good way to fix the bug. We shouldn't be trying to create TLS automation policies for servers that are HTTP-only. (Right? I keep feeling like there's some edge case in here I'm not considering. Oh well... guess we'll see.)

Please try the latest commits and let me know if there are any further problems. Thanks!

[0az]

Tested 3366384. LGTM.

[mholt]

Great, thanks!