Caddy: Caddy does not handle domains ending with a dot

[carstenhag]

1. What version of Caddy are you using (caddy -version)?

Caddy 0.9.5

2. What are you trying to do?

Trying to access a caddy server via an URL containing the domain ending in a dot.

So basically, https://caddyserver.com. is a valid domain/URL but it can't be accessed (notice the dot).

3. What is your entire Caddyfile?

4. How did you run Caddy (give the full command and describe the execution environment)?

5. Please paste any relevant HTTP request(s) here.

6. What did you expect to see?

The site being delivered as happens when the dot is not there.

7. What did you see instead (give full error messages and/or log)?

No such site at :80
No such site at :443

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

Run a caddy server or access https://caddyserver.com./

[francislavoie]

Correct me if I'm wrong, but I think the only thing that would make sense to fix this is to redirect removing the trailing ., otherwise TLS would break.

Relevant question: https://serverfault.com/questions/470719/https-and-trailing-dot-in-domain

[mholt]

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.

[carstenhag]

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.

[carstenhag]

See http://www.dns-sd.org/trailingdotsindomainnames.html for general information about the trailing dot.

[carstenhag]

Found another site listing sites which also do not support the dot. Maybe it's just better to redirect then. http://www.hitechyo.ga./2013/03/danger-of-trailing-dot-in-domain-name.html

[mholt]

@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.

[justjanne]

@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)

[justjanne]

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.

[mholt]

@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]

@justjanne Ugh, GitHub did not update the issue page on mobile when your next reply was posted. Anyway:

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

But these web servers do not do certificate management. Serving both names to the same site is easy. But there are real consequences here we need to understand better with regards to certificates. Other servers do not have the concerns we have because hostnames have extra significance to Caddy because it takes care of certificates for you.

[mholt]

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

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]

and Let's Encrypt won't issue for domains with a trailing dot, so the site can't be served securely anyway.)

Ehm, what?

I use a Let's Encrypt certificate on https://kuschku.de./, and your site ( https://caddyserver.com./ ) is also served securely.

The Certificate still matches today, and SOP also matches in my tests.

[justjanne]

I checked again, even Chrome matches kuschku.de and kuschku.de. against each other for SSL and SOP: http://i.imgur.com/BJSL4SQ.png

[mholt]

@justjanne Chrome and Firefox allow them to be the same when validating certificates -- but don't confuse SSL and SOP. That's a screenshot of an SSL certificate. They still treat the two domains as different for SOP.

[justjanne]

@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.

[mholt]

@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.

[justjanne]

@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./