Boulder: Wildcard Certificate Support

[hsivonen]

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]

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]

Filed https://github.com/letsencrypt/acme-spec/issues/64

[anfedorov]

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 [email protected], [email protected], or a couple of others. The emails listed in the whois info of the domain were also valid verification options.

[JasonSome]

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

[lenovouser]

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]

Pinging @jsha

[lenovouser]

Any updates?

[fpietrosanti]

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]

https://github.com/ietf-wg-acme/acme/pull/124 has been merged, this should be possible now, right?

[rolandshoemaker]

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]

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]

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]

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]

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

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

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

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]

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

[cpu]

https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

[rolandshoemaker]

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