{"action":"opened","issue":{"url":"https://api.github.com/repos/letsencrypt/acme-spec/issues/64","labels_url":"https://api.github.com/repos/letsencrypt/acme-spec/issues/64/labels{/name}","comments_url":"https://api.github.com/repos/letsencrypt/acme-spec/issues/64/comments","events_url":"https://api.github.com/repos/letsencrypt/acme-spec/issues/64/events","html_url":"https://github.com/letsencrypt/acme-spec/issues/64","id":57229061,"number":64,"title":"Support demonstrating that the ACME client speaks for a DNS wildcarded hostname space","user":{"login":"hsivonen","id":478856,"avatar_url":"https://avatars.githubusercontent.com/u/478856?v=3","gravatar_id":"","url":"https://api.github.com/users/hsivonen","html_url":"https://github.com/hsivonen","followers_url":"https://api.github.com/users/hsivonen/followers","following_url":"https://api.github.com/users/hsivonen/following{/other_user}","gists_url":"https://api.github.com/users/hsivonen/gists{/gist_id}","starred_url":"https://api.github.com/users/hsivonen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hsivonen/subscriptions","organizations_url":"https://api.github.com/users/hsivonen/orgs","repos_url":"https://api.github.com/users/hsivonen/repos","events_url":"https://api.github.com/users/hsivonen/events{/privacy}","received_events_url":"https://api.github.com/users/hsivonen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-02-10T20:07:13Z","updated_at":"2015-02-10T20:07:13Z","closed_at":null,"body":"Copying and pasting from https://github.com/letsencrypt/boulder/issues/21\r\n\r\nAccording to a presentation by Seth Schoen and according to brief inspection of the CA source code, Let's Encrypt is planning on not issuing wildcard certificates. IIRC, the reason given by Schoen was the lack of a method of checking that the ACME client really speaks for the whole domain subspace. Furthermore, it was observed that being able to quickly meant non-wildcard certificates for a particular host names in an automated fashion without payment makes wildcard certificates less necessary.\r\n\r\nThis doesn't address the wildcard use case that Sandstorm (https://sandstorm.io/) has: Minting randomly-generated host names all the time in order to generate new unguessable origins. In order for newly-minted origins to work immediately, it doesn't make sense to wait even for fast automatic certificate issuance. Also, I would imagine that as long as the Baseline Requirements don't exempt short-lived certificates from revocation infrastructure requirements, Let's Encrypt might not be too keen to have servers generate certs for throw-away hostnames all the time.\r\n\r\nTo address this use case, I suggest that Let's Encrypt issues a wildcard certificate when the ACME client can demonstrate that it speaks for several hostnames that are randomly generated by the Registration Authority. For some reasonable value for \"several\", the RA should be able to convince itself that there exists a DNS wildcard that makes hostnames that would match the requested wildcard certificates point to the server running the ACME client.\r\n\r\nThis issue is to request an ACME protocol addition for the RA to be able to present the client the sort of challenge described in the above paragraph.\r\n\r\n(CONTRIBUTING.md says I should email a mailing list, but the list name is a placeholder. Please let me know if I should email this somewhere.)"}}