Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wildcard Certificate Support #21

Closed
hsivonen opened this issue Feb 5, 2015 · 19 comments
Closed

Wildcard Certificate Support #21

hsivonen opened this issue Feb 5, 2015 · 19 comments
Milestone

Comments

@hsivonen
Copy link

@hsivonen hsivonen commented Feb 5, 2015

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

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

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

@bifurcation
Copy link
Contributor

@bifurcation bifurcation commented Feb 5, 2015

This is an interesting suggestion. It would require an update to the ACME protocol.

I would suggest we address this issue by first figuring out what the protocol looks like, then circling back to implement the updated protocol in boulder.

@hsivonen
Copy link
Author

@hsivonen hsivonen commented Feb 10, 2015

@bjacobel bjacobel mentioned this issue Apr 2, 2015
0 of 4 tasks complete
@bdaehlie bdaehlie added this to the Defer milestone May 19, 2015
@jcjones jcjones changed the title Issuing wildcard certificates isn't supported Wildcard Certificate Support May 20, 2015
@anfedorov
Copy link

@anfedorov anfedorov commented Jul 21, 2015

There was some discussion on the acme-spec issue about the possible implementations of this, although it looks like the final version left it up to the server.

The process I went through with COMODO for a wildcard cert I just got involved proving ownership of secret token sent to admin@domain.com, administrator@domain.com, or a couple of others. The emails listed in the whois info of the domain were also valid verification options.

@JasonSome
Copy link

@JasonSome JasonSome commented Jan 31, 2016

So, @bdaehlie @jsha any update on what remains to be resolved for wildcard certificate support?

@lenovouser
Copy link

@lenovouser lenovouser commented Mar 4, 2016

I think this should be possible now, as the DNS-01-Challenge has been implemented in staging. The client seems like it is going to support this soon too.

@JasonSome
Copy link

@JasonSome JasonSome commented Mar 12, 2016

Pinging @jsha

@lenovouser
Copy link

@lenovouser lenovouser commented Mar 28, 2016

Any updates?

@fpietrosanti
Copy link

@fpietrosanti fpietrosanti commented Apr 2, 2016

The Tor2web project would to use it and implement/integrate this specs from letsencrypt implementation as soon as it's available https://github.com/globaleaks/tor2web

@lenovouser
Copy link

@lenovouser lenovouser commented Mar 24, 2017

ietf-wg-acme/acme#124 has been merged, this should be possible now, right?

@rolandshoemaker
Copy link
Contributor

@rolandshoemaker rolandshoemaker commented Mar 24, 2017

ietf-wg-acme/acme#124 moves the wildcard issuance to a server policy position instead of a specification position. If a server chooses to allow wildcard certificates it will choose the set of requirements it needs satisfied based on its own policy for validating wildcards.

There is a possibility this could be further formalized (i.e. by providing a BCP policy for wildcard validation) but given the current WGLC state of this document this is not the place to do it.

@rolandshoemaker
Copy link
Contributor

@rolandshoemaker rolandshoemaker commented Mar 24, 2017

Blergh, thought this was an issue on ietf-wg-acme/acme.

Our position is that wildcard issuance is still not a high priority for Boulder, though it has now been unblocked by the specification update and is a possibility at sometime in the future.

@bdaehlie
Copy link

@bdaehlie bdaehlie commented Mar 24, 2017

We've considered issuing wildcard certificates in the past, and we're continuing to consider it, but we have no plans to issue them at this time.

@lenovouser
Copy link

@lenovouser lenovouser commented Mar 25, 2017

Well, that's at least a clear answer now. Until now the "excuse" was that wildcard certificate support wasn't implemented in the ACME specification yet.

@kachkaev
Copy link

@kachkaev kachkaev commented May 1, 2017

Wildcard Let’s Encrypt certificates could remove one serious privacy issue for those who use continuous integration and continuous deployment pipelines (CI/CD). It is to do with the public availability of all domains for which the certificates have ever been issued.

For instance, with GitLab it is possible to configure a git repo so that when someone commits to any branch or creates a merge request, a new temporary website is being created and made available at a custom subdomain. This helps developers continuously test their work and demo the changes to the management before the code reaches staging or production. Multiple versions of the same project are simultaneously available at example.com, staging.example.com, our-new-super-cool-feature.example.com, bug-fix-in-user-profile.example.com, bobs-experiment-with-payment-workflow.example.com, etc. (this list is dynamic).

When a team works in a cloud environment (e.g. deploys to a Kubernetes cluster), creating and running all these tens of websites ends up extremely cheap, because all the developers need to do is to just git push. And when Let’s Encrypt is properly configured within the cluster, all the test subdomains become effortlessly https-enabled out of box. A demo of this workflow can be viewed here: https://about.gitlab.com/2017/04/18/cloud-native-demo/.

It probably won’t be a surprise to anyone in this thread that due to the Certificate Transparency initiative, all the subdomains to which anyone has ever deployed anything, will land a publicly available list and stay there forever. Here are the hosts that the authors of the above demo have ever used: https://www.google.com/transparencyreport/https/ct/#domain=i2p.online&incl_exp=true&incl_sub=true

screen shot 2017-05-01 at 22 38 39
screen shot 2017-05-01 at 22 38 58

(the list goes on)

As we can see, there is quite a good chunk of potentially sensitive data!

The longer the team uses CI/CD, the more breadcrumbs are being left in the transparency report and the more harm this information can potentially cause. The most critical thing that can be leaked this way is a description of a security vulnerability within the product before a patch has become available – consider hackers discovering fixing-xss-in-search-form.example.com, which suggests that someone has just created a branch with such a name!

The more accessible CI/CD and cloud-native deployments become, the more teams start using them and the more prevalence of seamless Let’s Encrypt provisioning happens. With enough hidden complexity under the hood of the build tools, there is even no need to know that such thing as Let’s Encrypt exists at all in order to use it! Of course, strong dev teams will find means to protect themselves from the leaks by using paid wildcard certificates, but without a generally available free option to get a wildcard certificate, subdomain leaks are likely to spread quite widely.

Given the above, I believe that wildcard support for Let’s Encrypt should probably get a slightly higher level of attention than now. It's not only about reducing the number automated requests to the CA servers, as it turns out.

@kachkaev
Copy link

@kachkaev kachkaev commented Jun 14, 2017

@dosire do you think there might be a room for some collaboration between GitLab and Letsenctypt to solve the branch name leak issue through certs? See the comment above. Given that your team shows a great progress with CD to kubernetes/letsencrypt, the issue can become pretty wide-spread quite soon. Autogenerated wildcard certs to the rescue! :–)

@PAStheLoD
Copy link

@PAStheLoD PAStheLoD commented Jun 17, 2017

Just FYI, the current draft spec prohibits issuing authorizations for wildcards (which means prohibits issuing wildcard certs via ACME), however, LE seems to be making tiny steps toward issuing wildcards (such as introducing a new flow, and hints about a follow up spec for standardizing wildcard issuance).

@bjmgeek
Copy link

@bjmgeek bjmgeek commented Jun 29, 2017

Would another possible way to validate wildcard domains be to have an authoritative DNS server allow AXFR to the ACME server?

@rolandshoemaker
Copy link
Contributor

@rolandshoemaker rolandshoemaker commented Jul 17, 2017

Closing in favor of #2874 which contains initial implementation details for the v2 API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet