Please support Multi Domain SSL Certificates like the ones on positivessl


#4

@schoen but Multi Domain and wildcard are not the same thing. refer to https://casecurity.org/2014/02/26/pros-and-cons-of-single-domain-multi-domain-and-wildcard-certificates/ for more info.

@Meitzi How is it bad? Any smart site would have a user control panel allowing you to dictate what domains are allowed to use your multi domain cert. So if you lost a domain you could remove that domain from the list revoking its access and generating new keys automatically for your other domains. (This should be a thing and if it isn’t then someone should make it a thing.)

Also i think there is a misconception here.

The certs are stored on your server not the domain so even if you “lose” a domain you still own the server the domain was attached to. So the certs can only be used by you and they wont transfer to another owner unless you give them your server.

And when you lose a domain it’s always smart to disabled that domain from accessing your server via apache, ISS, or nginx configs by removing the server block or whatever in the non-nginx configs for that specific domain.

Who is telling you guys that your certs transfer with your domains? Because whoever they are they must be lying.

Your domains are registered with a Domain Registrar and the smartest thing to do is NOT host your server with that domain registrar. Take me for example all my domains are registered with https://www.dynadot.com/ and i have a VPS with https://www.vultr.com/ for the server. So even if i sold my domain to somebody else i wouldn’t give them access to my server because it has all my stuff on it and they need to go purchase their own.

I also have a cloudflare setup and my domain registrar points to cloudflares name servers. (for cache purposes)
I don’t see any problem with Multi Domain SSL. I don’t recommend it for those that can’t manage a server on linux or windows properly because that alone defeats the purpose of even having ssl in the first place since the servers won’t be secure anyway.


#5

Hi @Touma,

We are definitely planning to offer certs that use subjectAltName to cover multiple domains. In fact, support for this has been a major focus of client development, and is already working well in the client preview. A goal is to make it easy to reissue certificates quickly when you need to add or remove individual names.

I misunderstood the focus of your question and thought you were asking whether we could do exactly what PositiveSSL does. We can definitely do the multidomain part, just not the wildcard part!


Short certificate period - no useable on multi server scenario
Will Let's Encrypts own sites use Let's Encrypt certs?
#6

@schoen awesome and thanks for the quick reply.


#7

Your example here:

is a “multiple-wildcard” certificate.

Let’s Encrypt will let you issue a certificate for any number of non-wildcard domains; you just need to watch the size of the resulting certificate file.


#8

@riking
Actually its whats known as a multi domain wildcard hybrid certificate its what happens when you put several domains and a *.domain in a multi domain certificate.

I would also rather not use wildcard certificates unless i have 100 subdomains and have a check in place that checks if the subdomain is allowed to use the wildcard.

The example was to show that a multi domain certificate could do it as well.

Basically you can also put subdomains in a multi domain certificate. Which in my case would look like this

ilp.moe
stats.ilp.moe
db.ilp.moe
b.ilp.moe
s.ilp.moe
hack.ilp.moe
im.ilp.moe
toaru-anime.tv
stats.toaru-anime.tv
im.toaru-anime.tv
toaru-music.tv
stats.toaru-music.tv
im.toaru-music.tv
toaru-pic.tv
stats.toaru-pic.tv
im.toaru-pic.tv

Imo i’d rather use a multidomain certificate then 4 separate wildcard certificates since all the domains are on the same server.

Not to mention at least with the multidomain cert i can sort of restrict what domains and subdomains can use the cert. However in a wildcard i can’t restrict the sub domains so its less secure.


#9

That list of domains will be fine for Let’s Encrypt.


#10

Awesome that makes me happy. Oh also i plan to donate to this project 100$ by the end of the month because i like it :smiley: .
It would be nice if there could be a list of people who donated based on community names and the ability for those that wish to be anonymous to have no name.

Oh @riking

I have an xmpp server on im.ilp.moe will lets encrypt use pems or crt’s.
Pem’s are good for ejabberd (xmpp server)


#11

@Touma, the Let’s Encrypt client currently defaults to saving PEM files.

All of the file formats that various server software might want for certificate data are just different representations of the same data. You can convert between them with the openssl command in a single step.


#12

Schoen, This SAN functionality is really, really important, yet I’m only learning about it now. It should be part of the basic tutorial that everyone must read to use LE. Why do I say that? Because almost all webmasters support at least pairs of sites (https://example.com and https://www.example.com, at least). The client should by default offer to create or renew a certificate for both www and bare domains as a pair, IMO. Otherwise, when an end user connects to a website protected by LE, they may see the browser request to add an insecure exception to connect to the site, which then could be exploited by malicious users. Just my opinion.


#13

tend to agree… official LE docs/manual and examples should list it as an example


#14

We offer hosting for email, web services and the like for many customers that want to have secure sites. Previously we had to manage all the SSL certs separately which was a massive undertaking, even when scripted. We found the Comodo sold multi domain wildcard certs and we began using them which has reduced our operational time for managing SSL dramatically. There are applications such as dovecot and postfix which cannot utilize multiple certs which required an ugly system where we had to reverse proxy the SSL connection on our load balancers and caused headaches all around.

Implementing multi domain wildcard certs is going to be a critical feature of this product for serious hosting companies, and anyone who wants to simplify their sprawl of certificates. PRETTY PLEASE WITH CUPCAKES AND COCAINE ON TOP INCLUDE THIS AS A FEATURE.


#15

There’s not much point arguing for multi-domain wildcards when:

  • multi-domain is supported fully
  • wildcards are not

#16

Yes there is a point. We have thousands of subdomains in use on wildcard certs for our customers and our own services. We do not want to manage those thousands of subdomains individually, hence the reason we went with a wildcard cert in the first place. To add to that, we use a multi-domain wildcard cert so we only have to use one certificate for everything, which has reduced our OPEX drastically. So this ACME spec doesn’t support it? How do we change the ACME spec? Why is no one from LetsEncrypt explaining to the people in this thread how to move towards supporting this instead of telling people no? Can we help pay for some research? Can we participate in the development? Give us something instead of shooting us down, it’s incredibly insulting and beyond frustrating.


#17

Wildcard support is a separate issue from this; there’s a thread discussing it here (including feedback from LE):

Multi-Domain is fully supported as @riking stated.


#18

You send us to a closed thread so we can shut up about it? We have all already read that thread, why do you think I am asking about how to change the ACME spec and get this moving along?


#19

As mentioned in the thread, once the ACME working group agrees to include a verification mechanism for wildcard certificates, Let’s Encrypt will consider implementing it. There are some technical concerns, mostly regarding the Public Suffix List, that make this rather complicated for the moment, which is why it wasn’t included in the current version of ACME. There are some moving parts that might make this more viable in the future, like the dbounds working group. If you want to get involved, those working groups are a good place to start.


#20

domain.com
*.domain.com

Wildcards! Now! And not only because of reason to make it easier, but more for security.

Currently anyone can read all domains the certificate has been issued to. Also the pages which are not beeing communicated like Admin Interfaces.

The certificate reveals them all. One of my points not using this service…


#21

Security by obscurity doesn’t work. How hard do you think it would be to enumerate common hostnames used for admin interfaces?

If you don’t want your admin interface to be publicly known, don’t make it publicly available.


#22

This thread is turning into a referendum about wildcards rather that its original topic, SAN certs (which are already supported). I’m going to close this one; I’d definitely encourage everyone who wants to vote on wildcard certs to hit ‘like’ over at Please support wildcard certificates. Thanks!


#23