Please support wildcard certificates

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.


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.

CN =
CN = *
CN = *

Subject Alternative Name:
DNS Name =
DNS Name = *
DNS Name = *

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

1 Like

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

1 Like

+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:


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


@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

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:

Wanted to share another specific use case that requires wildcard certs. is a system that attempts to make installing open source apps easier for folks less tech-minded. When an instance is created, it uses a random wildcard domain. I’m not sure of the technical details, but you can read all about it on their website.

Let’s Encrypt wildcard cert support would be helpful for folks wishing to create a self-hosted sandstorm instance accessible via SSL/TLS.


It’s true wildcard certificates may be useful for these cases but I think a better solution would be for Sandstorm to integrate with LE directly and request/validate a certificate as part of it’s service deployment process. This would keep the complexity ‘behind the curtain’ so to speak and be a better choice for cross-subdomain security in general.


The volume of new hostnames a Sandstorm instance generates seems like it would get large quickly.

Paraphrasing from
Sandstorm creates cryptographically random hostnames for each session / user / application instance. Sandstorm also segregates documents into separate application instances where possible.

If I was to log in and create 3 etherpad documents, each document has its own hostname as each runs in a separate instance. If I share those documents with a friend, my friend will have a hostname for each document. If I step away and log back in, those 3 original hostnames I accessed documents with are destroyed and I have a new 3…

Sandstorm has a fascinating design, but it pretty firmly requires a wildcard cert. This could be a wildcard on a subdomain–maybe this limitation has value? It would be awesome if someone could install Sandstorm and start hosting their own web apps over HTTPS in a way they could share with a few clicks of effort.

Here’s a thread from the Sandstorm dev list!topic/sandstorm-dev/-CvczbyYgmo


We’re aware of this; the Sandstorm developers contacted us several months ago and explained their use case, which makes perfect sense. However, we told them that we couldn’t help them for the time being.

For the benefit of others, I did some research. As of the current date, the cheapest wildcard certificate available is $94/yr from Namecheap reselling Comodo (PositiveSSL brand).


[quote=“riking, post:27, topic:258, full:true”]
For the benefit of others, I did some research. As of the current date, the cheapest wildcard certificate available is $94/yr from Namecheap reselling Comodo (PositiveSSL brand).
[/quote] well there’s cheaper options if you go through resellers and such where you can get wildcards for between US$35-55/yr. I have reseller accounts with a few SSL providers and normally just resell to my private consulting clients or my Centmin Mod Premium members.

Still would be nice for Letsencrypt to offer wildcards as automation process will make it alot easier especially for folks looking at SSL certs for performance reasons i.e. SPDY or HTTP/2

1 Like

Personally, I’m in favor of LE waiting until they know everything is working right, and some of the weird edge cases are known, before trying to issue wildcards. I’m only running with 4 subdomains right now, so I would be happy with the standard client :slight_smile:


I also vote for wildcard certificates. Of course it’s possible to get by without them, but they make my server management so much easier.

One cert to rule them all!


At first I was thinking this was not a needed feature but I can understand the use cases presented. It is something I would like to see but having it at launch it not a damper on the project if you ask me. I don’t think we are going to see a mass exodus to Let’s Encrypt overnight and there will always be people I think that don’t trust it because it is free. I was thinking of using the service in my home lab where it is not feasible for me to spend hundreds if not thousands a year for certificates to run on hand me down hardware. While a wildcard would make this easier for me to add hosts as I try out new products or spin up servers I can live with having to do a few minutes of manual intervention and it is pretty easy to keep a text file or something with all of the SANs I need to reference. It also allows me to re-use a certificate on a server if I have to tear it down and rebuild it due to configuration issue or something. I would hate having a cert that is used for 4 days then never used again. Then on the other hand I see that being better than just using a wildcard to mask all of those changes.

Adding my viewpoint to help add some exposure to the topic.


+1 for wildcard support

1 Like

+1 for wildcard support

I have 4 domains and multiple sub domains and an xmpp server (ejabberd) on one of those sub domains.