This is a solution if you don't care that anyone looking at the certificate would be able to directly see every single domain that you are hosting as part of your setup.

Determined people would be still able to find it out, more or less, despite not having it handy in their web browser under the field for the certificate's Subject Alternative Name. However, there is nothing stopping you from issuing separate certificates for each domain (possibly with subdomains) and configuring your webserver appropriately with SNI.

I have been using precisely Nginx to serve multiple HTTPS domains with certificates from Let's Encrypt since the first few weeks after it came out, so I am not sure why OP thinks it's strictly necessary to assign them separate IP addresses. Generally speaking, there is nothing wrong with that, and it is indeed a somewhat cleaner solution, if it wasn't for the IPv4 examples, oh my...

I was under the impression that older clients wouldn't send the host header over HTTPS, making it impossible to determine the correct certificate to serve in a shared IP environment. Modern browsers all support SNI which prevents exactly this problem, but compromise by sending the hostname in plain text, which may be a privacy concern; this is something that's still up for debate: http://security.stackexchange.com/questions/86723/why-do-htt...

EDIT: I'm not sure what I was reading or who I was responding to. You mentioned this directly in your comment. Ignore my blathering, I'm tired. :)

They all send host headers over HTTPS (unless it's http2, because the protocol is different). But the host headers don't get sent until after the encrypted transport is fully setup. And to set up the encrypted transport, the server needs to send a certificate. So the server needs to send the certificate before it sees the host header. That's what SNI helps.

SNI doesn't work on Windows XP.

"Who still use Windows XP?" I hear you ask?

Just under 10% of all users[1]. Enough to make SNI problematic. In a few years time, we'll be OK, but not right now.

---

[1] https://www.netmarketshare.com/operating-system-market-share...

On internet explorer on Windows XP. Anyone on XP who uses Chrome or Firefox is just fine. If you are still using internet explorer on XP then you probably have other problems from all the malware that already installed itself on your computer.

Current versions of Chrome are no longer available for XP.

If you are still using XP it's probably because you have to, and do not have the knowledge to switch to something better. Ergo, it's highly possible that you are still using IE on XP as well, as you don't know any different, or cannot change it due to restrictions, or policy.

It's an accessibility thing. If I designed a new web system that blocked off 10% of the populous, for whatever reason (deaf,blind, not able bodied), then people would call me out on it.

In the main, it's unlikely that anyone still using XP is doing so because they want to. Not everyone is privileged enough to have access to modern equipment.

  It's an accessibility thing. If I designed a new web system that
  blocked off 10% of the populous, for whatever reason (deaf,blind,
  not able bodied), then people would call me out on it.

Rightly so, because that's a constraint that cannot be changed.

Running an outdated, decommissioned operating system is something that can be changed. You have no obligation, moral or otherwise, to support Windows 3.1, OS2/Warp, WAP browsers, Gopher clients, or IE5 running on Mac OS 9.

You can still choose to support outdated clients, because it makes financial sense for your organisation - and many places to just that - just as a corporation running outdated software may choose not to update because that's what makes financial sense for them.

Equating support for an accessible service with support for outdated browsers is a non-starter.

> Not everyone is privileged enough to have access to modern equipment.

And there you go. If you can't be bothered to not use an ancient operating system, that's just too bad. I don't care about people running DOS either.

Luckily it is a lot easier to switch to a modern operating system than to replace nonfunctional parts of the human body.

> I have been using precisely Nginx to serve multiple HTTPS domains with certificates from Let's Encrypt since the first few weeks after it came out

This is what I do as well, so I became pretty confused when reading the article. I've had no problems running my personal sites (side projects, really) from one NGINX server using different Let's Encrypt certificates for each one.

Also, plugging Caddy: https://caddyserver.com/

I used to be a huge fan of nginx and I haven't touched it in a year now. I don't miss it, Caddy is fantastic and handles the Let's Encrypt stuff for me.

I can never take caddy seriously until they get serious about updates and start working with linux packages.

When you have to do this: https://gist.github.com/Jamesits/2a1e2677ddba31fae62d022ef8a...

That means your webserver is not going to receive updates until you re-do this manually each time, which is dangerous and not at all something you should be using proffessionally.

It's the duty of distributions to pick up and package software. Maybe you could volunteer for the distro you use yourself? It is easier than one might think.

We will look into it after we hit 1.0.

Can anyone else speak to Caddy? My interest is peaked. I run several hundred thousand HTTP requests in a load balanced web cluster hourly, I'll do some reading, but has anyone else used it for high traffic?

I don't know anything about Caddy but for some reason I feel compelled to tell you that it's "piqued", not "peaked".

Caddy is pretty awesome. I use it to run my personal website (love that it can serve statically compiled Brotli assets out of the box). I maintain it's docker image here: https://github.com/ZZROTDesign/alpine-caddy :) Should be incredibly simple to set up!

How does Caddy compare to nginx performance wise? I have a similar setup like you running on nginx.

For loadbalancers I mainly care about performance and not usability of the configuration language.

I hear this question a hundred different ways. What do you even mean by performance? There's so many dimensions to a web server.

Any device that doesn't support SNI wouldnt be modern enough to support secure cyphers since weaknesses hav e been found in most of the older ones. Plus anything below TLS1.0 shouldn't be supported either (nor even TLS1.0 if you're running something where security really does matter). So you're better off dropping support for the aforementioned devices regardless of whether you choose to use SNI or not.

> You don't need multiple IPs and you don't even need SNI with its legacy client compatibility problems (now mostly well past). Just get a certificate that covers all the domains you use.

Horrible idea depending on your use case. If you are single-tenant, this might work out well for you.

If you are multi-tenant then the information leak is pretty nuts, and not something I can see any of my customers being alright with. That and the whole idea of giving the public access to my customer list is pretty silly to me.

Additionally in many environments the end-user can potentially access the private key on the server (think managed services environments) which is an obvious security hole. You'd think people would realize this, but in my experience they do not. In such cases you just let the private key walk out the door for every domain ever configured for that SSL certificate.

Not sure if you'll see this or if it's directly related. I also domain map but on an Apache server, this is probably an excuse but while I realize Let's Encrypt is free, and although there is the 90-day thing that you could automate, I just go with the year-long $9.00 certificate for each domain. I was wondering though, since it's domain mapped, the root domain can bridge to other sites by subfolders eg.

/var/www/html/main-domain | https://mainsite.com

/var/www/html/main-domain/domain2 | https://somesite.com

/var/www/html/main-domain/domain3 | https://somesite2.com

My question I could just easily try it, I'm not sure if it's related to what you mentioned where if you switch domains while logged into one if you'll lose session. I don't expect it to work. I just don't know what happens if people figured out "hey this ip is hosting multiple sites" and could figure out how to traverse each subfolder-site.

My question sucks sorry. I'll have to try it out I guess, at least my stuff is for myself not dealing with other people's info/sites.

This quesiton is related to information leak. I handle the domain mapping with virtualhosts. I also realized when you switch from say non-www to www (I saw you should stick with one) but when you do that you'll lose the session value so I imagine I'm safe.

I actually just took down one site as it was a useless domain so I can't test the multiple ssl certificates at the moment. Yeap this question is a waste of time my bad.

I was about to comment pretty much all of these points. As soon as I read about multiple IP's I wondered what was going on.

I'm starting my own tech blog for similar articles, maybe I'll do a simpler example for my first post.

Exactly.

I made this for exactly this usage: https://github.com/fenollp/nginx_ssl_compose

Just create a folder in ~/www for each host. It's been working great for around a year. Only interruption was due to docker destroying my containers during the upgrade of docker-engine. Great software guys...

Indeed this is what a SAN cert does. From Letsencrypt's FAQ:

"Can I get a certificate for multiple domain names (SAN certificates or UCC certificates)?

Yes, the same certificate can contain several different names using the Subject Alternative Name (SAN) mechanism.

Source: https://letsencrypt.org/docs/faq/

Even with AWSs load balancers? We are trying to solve this issue right now in house.

Any recommendations/war stories/further reading would be greatly appreciated.

Related forum post:

https://forums.aws.amazon.com/message.jspa?messageID=520926

Yes! I do with NGINX using SNI (to server multiple ssl certs from the same IP) and using Proxy Protocol on the ELB to send the requests to NGINX.

What you need to do is enable the proxy protocol on the ELB and then point to NGINX. http://docs.aws.amazon.com/elasticloadbalancing/latest/class...

You need to also enable the proxy_protocol in nginx.

  server {
    listen    443 ssl proxy_protocol;
    ...
  }

I'll write something up and share it. But hopefully this will help you in the short term.

That would be very kind, thank you. I'm not the particular dev who has been doing the research, but I might read his notes later to catch up to what he perceived as the pitfalls of using ELB with LetsEncrypt.

You need to use SAN certificates to do this (Which LE will do). You just need to be comfortable with having every domain registered appearing on the certificate.

"... setup and security and resource problems of SNI..."

As a user who really dislikes SNI, I would like to see someone write more about these problems.

You don't want to do this, as it's a privacy violation. It will let attackers know all the names of all the other websites you are serving, just by looking at one of those website.

Do you want people to know that your server for www.donaldtrumpisgreat.com/www.hillaryclintonisgreat.com is also serving your company's homepage?