{"action":"created","issue":{"url":"https://api.github.com/repos/mholt/caddy/issues/831","repository_url":"https://api.github.com/repos/mholt/caddy","labels_url":"https://api.github.com/repos/mholt/caddy/issues/831/labels{/name}","comments_url":"https://api.github.com/repos/mholt/caddy/issues/831/comments","events_url":"https://api.github.com/repos/mholt/caddy/issues/831/events","html_url":"https://github.com/mholt/caddy/issues/831","id":155563779,"number":831,"title":"Discussion: SAN certificates","user":{"login":"captncraig","id":192540,"avatar_url":"https://avatars.githubusercontent.com/u/192540?v=3","gravatar_id":"","url":"https://api.github.com/users/captncraig","html_url":"https://github.com/captncraig","followers_url":"https://api.github.com/users/captncraig/followers","following_url":"https://api.github.com/users/captncraig/following{/other_user}","gists_url":"https://api.github.com/users/captncraig/gists{/gist_id}","starred_url":"https://api.github.com/users/captncraig/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/captncraig/subscriptions","organizations_url":"https://api.github.com/users/captncraig/orgs","repos_url":"https://api.github.com/users/captncraig/repos","events_url":"https://api.github.com/users/captncraig/events{/privacy}","received_events_url":"https://api.github.com/users/captncraig/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-05-18T17:56:18Z","updated_at":"2016-08-27T01:49:54Z","closed_at":"2016-05-18T18:53:20Z","body":"I'm sorry to keep bringing this up, but I continually hit rate limits with Let's Encrypt, and issuing SAN certificates would reduce the pain of having a lot of subdomains all needing certificates.\r\n\r\n### Problem\r\nWith Let's Encrypt you are currently limited to 5 *certificates* per domain per week. At 90 day lifetime, this puts a hard limit of around 50 subdomains per domain, assuming you properly space your issuance over 10 weeks. Using SAN certificates, you can put up to 100 names per cert and greatly increase this number.\r\n\r\nMatt has repeatedly rejected the idea that caddy should issue SAN certs because it increases caddy's complexity by making multiple places to look for certs instead of the simple `$HOME/.caddy/sites/name` pattern. Also, we hope that LE will relax the limits and make this unnecessary, but I have not seen any indication on when/if that will happen.\r\n\r\n### Plugin?\r\nI was thinking today that *maybe* a plugin could handle this.\r\n\r\n```\r\na.mydomain.com {\r\n   san foo\r\n}\r\nb.mydomain.tld {\r\n   san foo\r\n}\r\n```\r\n\r\nA plugin could:\r\n\r\n1. Collect all domain names / san names at parse time.\r\n2. After all domains parsed, get caddy's LE account info, and issue certs using lego.\r\n3. Save certs in `.caddy/sancerts/foo.crt`\r\n4. (hopefully) implicitly add `tls .caddy/sancerts/foo.crt .caddy/sancerts/foo.key` to the relevant domains.\r\n5. Periodically renew certs and restart caddy.\r\n\r\nThis all seems potentially possible, but I am not sure if it would work because of caddy's startup sequence and if any of this will conflict with caddy's own certificate management steps.\r\n\r\nThat all feels like it is reproducing most of what caddy already does, and I am not sure if all of the things it needs to do that job are currently available to plugins.\r\n\r\n### Native?\r\n\r\nIt seems like baking this into caddy's own cert management system would not be too hard. \r\n\r\n```\r\na.mydomain.tld {\r\n   tls {\r\n    san #default.mydomain.tld.crt\r\n   }\r\n}\r\nb.mydomain.tld {\r\n   tls {\r\n   san foo #foo.crt\r\n  }\r\n}\r\nc.otherdomain.tld {\r\n   tls {\r\n    san foo #foo.crt contains multiple tlds\r\n   }\r\n}\r\nd.otherdomain.tld {\r\n  tls {\r\n    san #default.otherdomain.tld, default issues all certs for a tld together, but doesn't mix tlds.\r\n  }\r\n}\r\n```\r\nI like this for a couple of reasons:\r\n\r\n1. It must be explicitly activated. There is no ambiguity about where to look for a cert for a given server.\r\n2. Caddy can manage the san certs just like any other.\r\n3. Lego already supports this.\r\n\r\nThoughts?\r\n"},"comment":{"url":"https://api.github.com/repos/mholt/caddy/issues/comments/242888649","html_url":"https://github.com/mholt/caddy/issues/831#issuecomment-242888649","issue_url":"https://api.github.com/repos/mholt/caddy/issues/831","id":242888649,"user":{"login":"jleclanche","id":235410,"avatar_url":"https://avatars.githubusercontent.com/u/235410?v=3","gravatar_id":"","url":"https://api.github.com/users/jleclanche","html_url":"https://github.com/jleclanche","followers_url":"https://api.github.com/users/jleclanche/followers","following_url":"https://api.github.com/users/jleclanche/following{/other_user}","gists_url":"https://api.github.com/users/jleclanche/gists{/gist_id}","starred_url":"https://api.github.com/users/jleclanche/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jleclanche/subscriptions","organizations_url":"https://api.github.com/users/jleclanche/orgs","repos_url":"https://api.github.com/users/jleclanche/repos","events_url":"https://api.github.com/users/jleclanche/events{/privacy}","received_events_url":"https://api.github.com/users/jleclanche/received_events","type":"User","site_admin":false},"created_at":"2016-08-27T01:49:54Z","updated_at":"2016-08-27T01:49:54Z","body":"Reviving this discussion a little. I think it comes up often enough that this *really* merits reconsidering. Any website with a sufficient amount of subdomains will be hit by this, which means that one of caddy's and letsencrypt's main features become completely moot. This isn't just a SNI issue.\r\n\r\nThe code/logic complexity argument is valid mainly for the case of \"Caddy should figure out, all by itself, which certificates fall under which domain name\". It doesn't have to work like that, though. We can shift this decision making down to the user. Same for renewal failures.\r\nIf we make SAN an opt-in feature requiring changes to the Caddyfile, this puts all responsibility on the user.\r\n\r\nI've prototyped a few ways to do it and arrived to the syntax below:\r\n\r\n```conf\r\nsan {\r\n\t# Simple example: multiple subdomains attached to the same domain\r\n\texample.org one.example.org two.example.org foo.two.example.org\r\n\r\n\t# This is okay as long as the provider supports it\r\n\texample.net example.com\r\n\r\n\t# Error: Redefinition of an existing san rule\r\n\texample.org three.example.org\r\n\r\n\t# Wildcard example: Attach all subdomains matching example.com to this one\r\n\t# Alternatively, this could request a wildcard cert if an ACME provider ever offers those.\r\n\texample.com *.example.com\r\n}\r\n```\r\n\r\n A `san` rule would be defined and parsed early on. Before requesting any cert, caddy would have a lookup table of all the domain it wants, as well as which \"main\" server these fall under. In the above examples, if a cert is needed for `example.com`, Caddy knows to use the one in `example.net`. Bonus: Fully backwards-compatible.\r\n\r\n@mholt If a sufficiently clean and low complexity pull request was filed implementing such a system, would you take it? I think if Caddy becomes popular, SAN support will be a matter of when, not if - so we might as well figure out the wanted design :)"}}
{"actor":{"display_login":"jleclanche"}}