Please support wildcard certificates

[Moderator's note: if you want to express support for wildcard issuance, please hit 'like' on this post rather than starting a new thread.]

In your FAQ you write:

Hopefully wildcards aren’t necessary for the vast majority of our
potential subscribers because it should be easy to get and manage
certificates for all subdomains.

That is not necessary true for a few techniques that would quite benefit from Let's Encrypt. One new technique that will face unnecessary complexity without wildcard certificates is DANE.

I could use a different certificate for each FQDN that uses DANE. This would make it necessary to have a lot of different TLSA records that need to be managed in my DNS zone instead of CNAMEs pointing to one TLSA record.

Also, multiple certificates are not possible for something like mailservers which do not have SNI capabilities and which are the main beneficiaries from DANE.

So I would need a certificate with SANs and every time I add a new name to my mailserver I would need to reissue the certificate with an additional SAN entry and change the TLSA record in the DNS, raising the possibility of operator errors and complexity.

There are other scenarios which would benefit from wildcard certificates as well so please consider adding support for them rather sooner than later.

463 Likes

Wildcard certs aren't yet supported by the ACME protocol. There has been discussion on the IETF ACME mailing list (search link), as well as issue 97 at the original acme-spec github (Note that repo is mostly for historical purposes now that the IETF process has begun).

The conclusion was to tackle this in the working group / mailing list:

I agree [...] that this is a difficult thing that the WG should discuss.

2 Likes

I would like Wildcard support too. However, please ignore this request at this time because I see the value of getting your “launch product”, basic secure domain certificates working first.

This is a good request, but I think it is best to ask for wildcard support in a year or two down the road, after the initial product release.

Remember folks, the support of this great product is not just the product itself. It is the entire infrastructure around it.

6 Likes

Yes for example HPKP too. This way you could include one HPKP header at all domains, with the includeSubdomains directive without worrying of different certificates for different subdomains.

3 Likes

Why should we not ask for wildcard support right now? They can always implement it after the launch. By the way, I don’t ask people to ignore your requests…

11 Likes

+1 for wildcard support later on.

3 Likes

@yayoubetcha I’m sure that the LE group has the capacity to prioritise and manage requests themselves, no need for you to jump in front of @gpf 's valid and desirable suggestion.

6 Likes

+1 for wildcard support :smile:

5 Likes

Libraries around the world use a product called EZproxy to connect library patrons to licensed resources. In order for the connection between the patron and EZproxy to be encrypted, EZproxy requires the use of a large number of nonstandard ports OR wildcard certs. The wildcard certs method is the most reliable for end users. Libraries would like to be able to support encrypted traffic for their users: whenever https is discussed, the need for wildcard certs for the proxying is raised.

Here’s some details - i’d be happy to discuss library+EZproxy needs further:
https://www.oclc.org/support/services/ezproxy/documentation/cfg/ssl/certopts.en.html
https://www.oclc.org/support/services/ezproxy/documentation/portvshostname.en.html

5 Likes

+1 also in favor of eventual support.

The primary case I hope to use wildcard support for can well be solved by individual subdomains. What I would really have loved to do for a long time now is simply…

https://fc353094d1dee.api.client.com
https://dff397b15db53.api.client.com
etc…

The wildcard in this case being a placeholder for an account’s API key. In this situation I’d actually rather manage the individual certificates server-side on the VPN using an internal authority and wildcard on the client-facing side. (i,e. servers reject non-validating subdomains internally but present the wildcard cert to the internet)

I wonder if any of you have any recommendations? An added benefit to using wildcard is a reduction in requests to LetsEncrypt registration servers.

1 Like

Another +1 for wildcard certificate support. Really do not want to manage a cert for each subdomain. Right now I use a single self-signed cert for all subdomains.

www.domain.com
smtp.domain.com
pop.domain.com
imap.domain.com
webmain.domain.com
. . .
and the list goes on.

2 Likes

NOYB, you can list all of those in a Subject Alternative Name and only have a single cert to cover those names.

Let’s Encrypt will support that at launch.

10 Likes

Thanks JC for pointing this out.

Yes using SAN only instead of wild card will work, but means the cert is limited to those. Have to get a new cert for adding or changing subdomains.
Using wild card provides greater flexibility with greater ease. Really prefer being able to continue using wild card cert.

Currently using self-signed wild-card cert with the following subject and subject alternative name.

Subject:
CN = a-domain.com
CN = *.a-domain.com
CN = *.a-subdomain.a-domain.com

Subject Alternative Name:
DNS Name = a-domain.com
DNS Name = *.a-domain.com
DNS Name = *.a-subdomain.a-domain.com

Can change or add subdomain names at will without having to mess with creating and installing additional certs. Much preferred.

2 Likes

I think that the answer for now is, if you need a wildcard certificate, go pay for one.

2 Likes

+1 as well… I predominantly use wildcard SSL certs these days with some domains having up to 80+ subdomains covered under the one wildcard SSL certificate :smile:

2 Likes

Isn’t the point of Let’s Encrypt that getting a new certificate is easy? I too have several hosts from a single ip address like @NOYB. I’ve never put the ip address in the SAN before, but I probably will with Let’s Encrypt because it should be easy to get a new cert if it changes.

Or do I misunderstand something?

1 Like

@docwhat, that’s definitely a reason that we think most users won’t need wildcard certificates as much as they have in the past: if they have a new host they should be able to get a new cert that includes that host for free in one minute.

But some people have described use cases where this is a problem: examples include deployments that have thousands of hostnames, or where the hostnames are dynamically generated by software (In the latter case, the administrator doesn’t even necessarily know ahead of time what hostnames will exist or will be accessed by clients.)

8 Likes

@docwhat @schoen I agree with that sentiment but it is unclear to me if there’s a threshold of incoming request per user that LE would find to be negative.

Is there support for submitting batches of different individual certs / could that be an easier route?

I’ll add my request for wildcards to the list too please. Will be useful for devices on the lan etc.

Cheers, Mark.

1 Like

@schoen maybe as an alternative is using SAN and allow a preset template of common subdomains to listed.

So end user could create a template of common subdomains

sub1.domain.com
sub2.domain.com
sub3.domain.com

Then run the client against the template and generate a SAN SSL cert with those subdomains ?

Some folks like myself have common subdomain hosts which I create i.e. blog, news, support, forums, community, portal, downloads, email, mail, shop, cdn, cdn2, cdn3, image, image2, image3, static etc. For subdomains I have a preset ist of ~100 subdomains which are most used for myself :slight_smile:

ssl crt, csr, and key size wise it would be much larger though. Probably, would help to have ECC 256 bit SSL support so that you can reduce the size by up to 66% :slight_smile: