Wildcard domains - not quite working as expected


(Dean Taylor) #1

Summary

Seeing odd issues when attempting to use Let’s Encrypt wildcard

I’m sharing these here for the developers as it might point in the directions of bugs - hope this helps.

  • Trying to avoid Let’s Encrypt Rate Limits for wildcard domains.
  • Attempting to use tls { wildcard \ dns route53 } to force use Let’s Encrypt wildcard cert.

The setup / outline

Building using the following:

docker run --rm -v $(pwd):/install -e PLUGINS=cache,expires,route53 -e VERSION=0.11.0 abiosoft/caddy:builder

Note:

  • I specify the version number else I seem to get a 0.10.11 build.
  • 0.11.0 appears to be the latest build so I believe I’m on the latest.
  • Version verified with caddy -version.

Problems / Oddities noticed

1. Wildcard specified hosts not accepted

It seems odd to get the following error when adding “wildcard” to the tls section:
/etc/caddy/Caddyfile:172 - Error during parsing: Cannot convert domain name '*.exmample.com' to a valid wildcard: already has a wildcard label

Changing the first config section in the Caddyfile from:

http://*.example.com,
https://*.example.com {
	cache {
		status_header X-Cache-Status
	}
	proxy / 95.142.xxx.xxx {
		transparent
	}
	tls support@example.com {
		ask http://internal-host.example.net/?action=domain_ask
	}
}

to:

http://*.example.com,
https://*.example.com {
	cache {
		status_header X-Cache-Status
	}
	proxy / 95.142.xxx.xxx {
		transparent
	}
	tls support@example.com {
		dns route53
		wildcard
	}
}

So in order to avoid this “valid wildcard” error I remove the “wildcard” specifier under “tls”.
My initial thoughts were this should work.

2. Wrong SSL certificate delivered

During other configuration changes I believe the configuration was close to the following…

http://www.example.com,
https://www.example.com {
	cache {
		status_header X-Cache-Status
	}
	proxy / 95.142.xxx.xxx {
		transparent
	}
	tls hello@example.com {
		dns route53
		wildcard
	}
}

to.example.org,
to.example.net {
	proxy / spgo.io {
		transparent
	}
	tls support@example.com
}

… when this oddity occurred.

For a request to https://test1.example.com delivered the certificate for to.example.net.


(Matthew Fay) #2

Using www.example.com with tls wildcard will tell Caddy to present the wildcard certificate to requests for www.example.com but does not configure Caddy to serve any other subdomain than www.

Since Caddy isn’t configured to serve test1.example.com, and no broad or catch-all site labels apply, Caddy goes back to its default behaviour for requests for a hostname that isn’t configured; it presents a certificate at random, then responds with a 404 site not served on this interface.

The wildcard subdirective isn’t necessary, just useful when you want to specify a specific subdomain should use a wildcard certificate rather than a single named certificate.

The correct form for your use case should be, if I’m not mistaken:

http://*.example.com,
https://*.example.com {
  tls support@example.com {
    dns route53
  }
}