-
-
Notifications
You must be signed in to change notification settings - Fork 593
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
Comments
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. |
Filed letsencrypt/acme-spec#64 |
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. |
Pinging @jsha |
Any updates? |
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 |
ietf-wg-acme/acme#124 has been merged, this should be possible now, right? |
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.
|
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. |
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. |
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. |
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 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 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 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. |
@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! :–) |
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). |
Would another possible way to validate wildcard domains be to have an authoritative DNS server allow AXFR to the ACME server? |
Closing in favor of #2874 which contains initial implementation details for the v2 API. |
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.
The text was updated successfully, but these errors were encountered: