Support for OnDemand even for non-wildcard domains

[matt (Matt Holt)]

Hey David, welcome! Nice job diving into this. Not bad for a new Go programmer.

If I understand the problem statement correctly, you might be able to work around this behavior by using a wildcard domain for each site in your Caddyfile:

*.usersite1.com {
    tls {
       max_certs 1
    }
}
*.usersite2.com {
    tls {
       max_certs 1
    }
}

I don’t know if that’s allowable in your situation, but if it won’t hurt, I think this would be better than the patch. Here’s why.

@dpp

(1) if a domain, even a non-wildcard domain, is specified as OnDemand TLS, then the cert is only retrieved when the site is accessed

I think my suggestion above should work around this, and…

@dpp

(2) added an explicit on_demand property to the tls configuration so one can specify OnDemand without max_certs.

Enabling on-demand issuance without any caps is dangerous, since certificates take up space on disk and someone could DoS your service just by making bogus handshakes all day long.

Also capping the max_certs to 1 as I’ve done in my example above assumes that the first handshake is for the correct hostname, so you hope it comes in first (!!) before any other bogus handshakes do.

Note the max_certs count is reset when Caddy is restarted, but if a valid certificate is already on disk, Caddy will use that instead of getting a new one.

We just have to be really careful changing any of the on-demand logic.

So, I know you’re not gonna like this, but here’s the best solution to the problem: have the domain point at the machine before starting Caddy. Or – I don’t recommend this unless you implement this carefully – you can disable TLS for their site with tls off until they point their domain to your server. But turn TLS on as soon as they do, of course.

@dpp

PS – If there’s anything I can do better to approach this community, I’m open to feedback. I appreciate the work of every open source community member and want to make sure I’m doing things to optimize for the community.

This is a great start. I usually like to direct these specific dev-related discussions into issues on GitHub so we can track it better. You can take a gander at the contributing guidelines if you find that helpful. Would love to have you a part of the community.

@dpp

Given my lack of Go skills, I don’t know how to fork a GitHub repo and create a pull request that is also compatible with Go coding which seems to force one into a single branch, master, from the original author’s repo.

Yeah, this is kind of an annoying aspect of Go OSS development. There is this one weird trick, though, that allows you to do it quite easily, by manipulating your git remotes: How to contribute to a Go open source git repo