Feature request - reconsider easier wildcard certificates in Caddyfile?

3 years have passed since this topic came up. I am coming from selfhosted world, and where caddy is often enough used for reverse proxy.

I was reminded of this topic when a post came up about being able to see all declared subdomains for any domain. dnsdumpster.com

Wildcard would solve this bit of exposure, but its so damn ugly in the config. To be forced from get-go one layer deeper and have extra declarations :confused:
Guides/tutorials with this would also be less clean or harder to write/understood.

My wish would be declaration in global option and to apply to naked/root domain and all its subdomains. I think overwhelming majority of people dont have need to babysit root domain separately, so simpler it is - better. But I have limited hands on experience.

Just thought I ask, as maybe with more work put in to caddy in recent years, some easier way to make this happen came to light maybe.

That pattern is the exact way it must be for Auto HTTPS to correctly apply. Please consider the JSON output of a Caddyfile with that pattern (run caddy adapt --pretty).

The rules for Auto HTTPS is that it reads top-level routes, looking for routes with host matchers. Those hosts are then automatically considered to create any relevant TLS automation policies if there aren’t already automation policies for those hostnames (subjects) already (there could already be some via tls config in the Caddyfile).

Because of that rule, if more specific sites are defined (i.e. a site foo.example.com) while a wildcard covering it also exists as a site (i.e. *.example.com) then Auto HTTPS will create an automation policy for foo.example.com as well because there’s nothing that prevents it from considering more-specific sites for automation.

Essentially what you’re asking for is to add more complexity to Caddy to get around these Auto HTTPS rules. That’s the thing we have a problem with. The code for Auto HTTPS is already very complicated and difficult to reason about. If we add more conditions or modes to it, it’ll be even worse.

In the case of wildcard certs, it feels like a “solved problem” already in the sense that there’s a pretty easy way to work around it by using a single site and having the host matchers inside of it to “hide” them from Auto HTTPS.

I’m not saying it’s not true that the config is not as ergonomic as we’d like regarding wildcard certs, you’re right that it is unfortunate. But it does feel hard to justify adding more complexity to an already complex system to improve it.

Regarding the reddit post, I disagree with the paranoia over CT logs. Domains are not secret information. You should be using authentication to prevent users you don’t want from reaching those services. It’s pretty easy now with options like forward_auth to set up single-sign-on for all your subdomains.

FYI I was doing some more thinking about it and there might be a path forwards but we can’t promise anything.

Well, caddy has been rock solid for me, so I would not trade that for cleaner config if it would bring up unnecessary complexity… so no pressure.

1 Like

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