caddy: Caddy does not handle domains ending with a dot

@mholt: So. I asked a few friends at Google and Amazon, and checked myself.

Google Cloud Engine’s TLS terminating Load Balancer automatically treats domain.tld. the same as domain.tld

The same with AWS.

And CloudFlare.

And the popular kubernetes project kube-lego with the nginx-ingress, which automatically creates TLS certificates via Lets Encrypt and assigns them.

Out of all projects that automatically handle this, including far more mature ones, yours is the only one that doesn’t do this.

As I migrated my infrastructure now to Kubernetes with kube-lego, you can see a demo on https://microbot.kuschku.de./

@mholt: So, either

1. https://caddyserver.com./ is running an old version of Caddy and should upgrade.
2. You get a working page when accessing https://caddyserver.com./ ?
3. If you say this is a configuration issue, then you’re saying https://caddyserver.com./ is misconfigured? (Which would lead to the issue if having to add a redirect maybe isn’t exactly the best way to approach that issue)

@carstenhag Closing an issue doesn’t mean we won’t respond to it. 😉 It just means it’s not on our TODO list.

I closed it because:

1. Yes, I do need answers to 3, 4, and 5 - so I can reproduce your issue.
2. I could not reproduce your issue
3. You’re using an old version of Caddy, please upgrade first.

I should not need to include a dot after the domain name in the config file, because example.com and example.com. is the same thing, speaking domain-wise.

If you had filled out questions 3, 4, and 5, I would have understood this is what you were getting at.

Given that Caddy does handle localhost and localhost. properly, I don’t see a need to act on this: it’s literally one line to set up a redirect:

localhost {
    ...
}

localhost. {
    redir http://localhost:2015{uri}
}

Thanks for your clarifications! I hope this ^ is helpful.

Replicating the issue on my side in Chromium 58.0.3029.81 and Firefox 55.0a1:

1. Access https://caddyserver.com/
2. Access https://caddyserver.com./

Expected Result: Both should return the exact same value.

Actual Result: https://caddyserver.com./ instead returns No such site at :443

Additional Info:

Apache, Nginx and IIS automatically handle domain.tld. the same as domain.tld.

The original RFCs on this are also clear – the actual name of a domain is always the Fully Qualified Domain Name, ending in a dot and after that the label of the zone. The root zone for DNS is unnamed, therefore every domain canonically ends in a dot. Most systems have a stub resolver that resolve any domain containing at least one dot as a FQDN by appending a dot, but the canonical name always ends in a dot.

Quoting RFC 1034 3.1 (page 8) here:

When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots (“.”). Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot.

@justjanne Caddy does support it, but it’s up to the site owner to figure out how to handle that: does it redirect (possibly breaking internal routing), or does it treat the site as the same as the non-dot version (possibly breaking with SOP)? This is a decision the site owner must make, I think, and so I’m going to leave it at that for now, unless there’s a truly compelling reason to make assumptions.

I did not fill out 3-4-5 because it affects all versions of caddy and all configurations.

@mholt I do not understand why you closed this issue, as it clearly works on every other web server but caddy. Edit: Okay, not every server but most. See new comment.

Just take https://serverfault.com./questions/470719/https-and-trailing-dot-in-domain as example, on Chrome and Firefox it works (Edge is too stupid and makes a bing search), the server handles everything correctly.

I should not need to include a dot after the domain name in the config file, because example.com and example.com. is the same thing, speaking domain-wise.

@francislavoie TLS breaking is also not valid. Just try out any TLS-enabled site and it will work with a dot at the end.

I find it quite annoying that my issue was closed without any further ado - let me clarify things, don’t just close it.

I’ve been looking into this a significant portion of the afternoon and asked a few people who know more than I do. 😄

It’s worth noting that most browser SOP (same-origin policies) reject example.com. as being the same origin as example.com - which, in practice, means the domains are actually different. IMO. (See https://labs.detectify.com/2016/10/05/the-story-of-ev-ssl-aws-and-trailing-dot-domains/)

Specs are either in disagreement or undecided here, since none of them that talk about it are doing so in the context of HTTP specifically. I think how to use the trailing dot is best left for the site owner to decide, if they need it for some reason. But this is the first I’ve ever heard of it in this sense, and no compelling reason has been presented to add this complexity to Caddy. (Other than "I want to access caddyserver.com via caddyserver.com., which is not compelling to me. Is your intranet resolving caddyserver.com to caddyserver.com.something.else? If so, redirecting to the host without the dot won’t resolve successfully, and serving with it will introduce problems with AJAX, cookies, and other basic web technologies. Serving the same site on both hostnames is the other option, but then you have the SOP problems, and Let’s Encrypt won’t issue for domains with a trailing dot, so the site can’t be served securely anyway.) Another discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=134402

I think I’ve just convinced myself out of doing this entirely.

@justjanne As I understand it, this issue isn’t about the Caddy website; I haven’t configured Caddy to serve the domain with a trailing dot. That’s just my decision as the site owner. It depends on the HTTP client as to whether the domain keeps it’s trailing dot; that is for the DNS resolver.

RFC 1034 says the two domains are the same, but RFC 3986 says they are not. I can’t tell from the http spec whether the two Host values are equivalent or not.

Chrome evidently treats both domains as equivalent when validating certificates but how we handle this depends highly on what Let’s Encrypt’s issuance policy is and how other major clients handle this, too.

Until then, I think it is best to take the conservative approach and not change this until we understand the consequences. It’s also not a priority. Users who care can manually configure the trailing dot hostname, and with the given information here and the vagueness of the RFCs, I don’t think most users will care enough to be impacted by this.

More investigation and understanding is needed before making a change here. I’ll mark it as deferred so we can revisit it later, but I’m not convinced as of now that this is a pressing need.

@mholt: Apparently, since a recent (a few years ago) change, they actually treat SOP separately. But SSL still validates.

Sites where it works, btw:

• https://www.google.co.uk./?gws_rd=cr&ei=6JUJWZrEFofWwAKvuY3ACQ
• https://www.apple.com./
• https://www.microsoft.com./de-de/

Basically, every relevant site out there supports it, every webserver supports it. Yours is the only webserver with a slightly relevant marketshare that doesn’t.

Hi @carstenhag - thanks for filling out some of the questions but I really wish you had filled out the template completely, because there’s not enough information to fully investigate and answer your question.

Let’s Encrypt apparently won’t issue for domains with the trailing dot: https://github.com/letsencrypt/boulder/issues/2367

But this Caddyfile worked for me:

localhost.

The Host header of the request then is localhost.:2015 and I see the index page of my site.

It seems that curl is stripping the trailing dot, if that’s what you’re using. But it works for me in Chrome.