Can you serve multiple HTTPS sites from a single IP address?

For HTTP you can, but maybe no for HTTPS?

[SumGuy]

I'm still struggling to get our IIS4 server to create / accept an SSL key / certificate in order to test a possible theory that some people (or some browsers, or google-search) is turned off by our HTTP site. The latest bottleneck is that NT4/IIS4 seems to be limited to (creating or accepting) a 1024-bit key, and nobody will generate anything less than 2048-bit keys (or certificate, sorry, not exactly up to speed with the lingo). But that issue aside....

One bit of info I've stumbled across is that we may not be able to serve multiple HTTPS sites from our single IP address (but we currently do serve a few different http sites with our current IIS4 server). And it wouldn't necessarily matter what our server is running (IIS 5 or 6 or 7 or apache. etc). What's the deal with that?

[keyplyr]

Can you serve multiple HTTPS sites from a single IP address?

Of course. That's what shared hosts do.

You may want to look at A Records.

[SumGuy]

> You may want to look at A Records.

Yes, the host records (a records) for our domains all point to the same IP address.

Have a look here:

=================
This is also why https sites *must*** have their own IP address -- the ssl key exchange and certificate verification take place prior to the http transaction, so the http server won't know to give out the certificate for "woodstock.org" or "snoopy.net" when it receives an https connection on port 443 of (your server's IP address).

[serverfault.com...]
=================

[keyplyr]

Again, you can have as many domains as you like on one IP address. Just change the A records to point to the appropriate files.

There are currently over 800 (both HTTP & HTTPS) sites on one of the servers I use.

You'll need a cert that covers the different domains, either by wild card or by inclusion.

[fix typo]

[edited by: keyplyr at 4:21 am (utc) on Nov 1, 2018]

[lucy24]

In a word: Nonsense.

Now, I've got a vague recollection that some unspeakably ancient browsers can't handle https unless {combination of circumstances including requirement for unique IP}, but unless you've got an extremely niche target audience, that's nothing to be concerned about.

Edit: The above was a reply to OP, not to keyplyr. At least not this time, mwa ha ha. We overlapped.

[keyplyr]

Note: I've been trying to get overlapped all week.

You could even do this with subdomains, however if you manage your server just add records.

[justpassing]

Can you serve multiple HTTPS sites from a single IP address?

Yes you can.

You can also have one TLS certificate for each domain (or sub domain) if you want.

All what it requires is that your server (software) supports SNI (Server Name Identification) : [en.wikipedia.org...] . So for example, in the case of IIS, this is only since verison 8, that SNI is supported (2012).

However, in that case, the domain name (hostname) is transmitted in plan text over the Internet during the negotiation handshake. This has very limited implication, from a security point of view, but still, an eavesdropper can know what a client is visiting (the hostname, not the page).

And of-course it requires the client browser to support SNI too. Otheriwse, the only solution is to have one certificate, in which ALL hostnames are listed.

[robzilla]

Have a look here

If you read on, you'll find an edit noting that "there are extensions to SSL in the TLS spec that allow the server to know which web site the user as attempting to access, and that most modern web browsers have these extensions, so must is a bit too strong." I would add that "must" is not just too strong but also largely incorrect. The exception being that you're apparently running web server software from the 90s ;-)

[justpassing]

most modern web browsers have these extension

96.09% of web browsers are supporting SNI : [caniuse.com...]

[LifeinAsia]

You can also easily do it with a proxy server/load balancer in front of the web site (which will have a single IP address itself- again showing that a single IP address can have multiple SSL certs).

We have Pound in front of multiple sites that all have the same public IP address (which points to the Pound server). Most of the sites are on one server (with the same internal IP address, but that's irrelevant to the cert itself). The beauty of this setup is that you can still use ancient technology (like NT4) behind it, because the Pound server is the one with the keys.

I don't believe that Pound runs on Windows, so you'd need a separate Linux box for it. But it's very lightweight, so you could put it on just about any old PC where you could install Linux.

[dstiles]

I run several https web sites on one IP, each with its own certificate, on Windows IIS 8 (2012 server). Earlier versions of IIS won't do it. You have to set up the Binding to use SNI (Require Server Name Indication) in IIS Manager.

[SumGuy]

So what I've done is to set up Aprelium's Abyss web server on an a spare win-7 box with one of those no-cost SSL certificates and copied our website files to it, and routing port 443 to that box. Looking at the logging configuration, Abyss allows me to "build" the log output by selecting individual fields from a list, and from that I've selected the Accept-Language, Character set and Encoding (along with the usual stuff - date/time, source IP, requested page, referer, user-agent, etc). I thought those "request headers" were somehow special and required extra magic/scripting/whatever to get - after all I wasn't seeing it in my IIS4 logs, but here I see it's probably always transmitted by browsers and simply not captured / logged by IIS for some reason.

So at the present time, neither server (http and https) knows about the existence of the other, and I don't believe that the search engines know that our site can now respond to https requests. I'll let this run like this for a while and see what hits us on port 443 and figure out later how to let google know about it. Abyss will run on NT4 (even win 9x/me) so I will (soon) move it to the same NT4 box running our IIS4 http site.

[dstiles]

Be aware that Win 7 will not fully support all the required HTTPS features. Nor will any Windows OS earlier than Windows 2012 Server, and even then it's marginal.

There are a few web sites that can help in hardening web servers, such as Qualys and Scott Helme. Well worth running them against any HTTPS server you set up. Also, there is a posting at [webmasterworld.com...] that deals with the subject.

[SumGuy]

> Be aware that Win 7 will not fully support all the required HTTPS features

Not sure what features you mean. I hit the Abyss https server (from inside the lan or from the outside) with a few different browsers and I get the padlock thing and no complaints. And when I move this from the win-7 box to our NT4 server - are you saying that it will get worse?

> There are a few web sites that can help in hardening web servers

Why would the Abyss server, serving the same exact files/site that my IIS4 server was serving, have any vulnerabilities? My site has no script files (not any of the dozens of wordpress, php or other junk I frequently see being requested by bots).

I ran the ssllabs test and got 100 for certificate, 95 for protcol support, and 90 for key exchange and cipher strength (overall rating A).

Here are the handshake simulation failures:

Android 2.3.7 No SNI Server sent fatal alert: handshake_failure
IE 8 / XP No FS No SNI Server sent fatal alert: handshake_failure
Java 6u45 No SNI Server sent fatal alert: handshake_failure
OpenSSL 0.9.8y Server sent fatal alert: handshake_failure

Regarding our key:

Key RSA 4096 bits
Weak key (Debian) No
Signature algorithm SHA256withRSA
Certificate Transparency Yes (certificate)
OCSP Must Staple No
Revocation information OCSP
Trusted Yes (Mozilla Apple Android Java Windows)

And guess what. I can even bring up the site on my win-98 system with firefox 2.0.0.20!

[dstiles]

Have you read (and installed) the first post in my link? They are very important. It's not the scripts that YOU provide but what criminals can inject into the output stream from your site to affect your visitors.

[SumGuy]

> It's not the scripts that YOU provide but what criminals can inject into the output stream from your site

How exactly can they do that? My site does not link to anything or serve anything that is not on my server, and I thought that with https that the "pipe" between my server and the endpoint browser is basically invulnerable to tampering.

[justpassing]

If the HTTPS frontend and the HTTP (without S) backend is on the same server, there is no risk (at least no more risk than if the server itself is compromised). If the frontend and backend are running on the same server but in different WM, be sure that the connection remains internal to the server and is not passing by an external router.

If the HTTPS frontend and HTTP backend are on different servers within the same Datacenter, the risk is "low", but a compromised router equipment can still inject malicious code.

If the HTTPS frontend and the HTTP backend are in different Datacenters (like for example, all those using Cloudflare to claim their site is HTTPS), there is a significant risk (the more you multiply the number of nodes , the higher the risk is).

[SumGuy]

I've noticed that bing and google are regularly hitting my https site for the past 3-4 days now (took them only maybe 12 hours to discover it, which must mean they have a habbit of testing for https). I have nothing in my domain records or any re-directs from the http site pointing to the https site (I'm guessing that I should set something up?). Doing a google and bing search for terms that bring up SER links to my site today still shows that the url's they are giving are to the http site. Will they eventually give https links, or will I have to do more on my end first? Or will it just take time?

[lucy24]

I have nothing in my domain records or any re-directs from the http site pointing to the https site (I'm guessing that I should set something up?).

How tempting it is to reply: NSS.

It is a pretty safe universal rule that any given content should be reachable by only one route. HTTPS, domain-name canonicalization, index, trailing slash, spurious parameters--you name it.

[SumGuy]

> It is a pretty safe universal rule that any given content should be reachable by only one route. HTTPS,

I've found some questions asked on stack exchange 4 or so years ago where someone was asking what the default behavior of browsers are when you type in a domain (with or without www. doesn't matter) will the browser first test for https or just go to http, and it seems that browsers go to http (port 80) and if https exists then there will be a re-direct to port-443. After that, it seems that browsers will remember the next time you hit that domain to automatically go to port-443 (until or unless you clear the browser cache I guess). There seems to be some add-ons that alter behavior so port-443 is the default first-access. Don't know if any of that is different for browsers in 2018 vs 2013.

I would _expect_ that since google and bing are now hitting me on port-443 and crawling the site, that they would offer the port-443 connection (https) in their SER links without waiting for me to basically turn IIS4 into a dumb re-director to the port-443 Abyss server.

I'm now running the Abyss server on the NT4 box with 4096-bit certificate (letsencrypt) and it's working just fine. I guess Abyss handles all the cryptography without needed anything from the OS?

[phranque]

it seems that browsers go to http (port 80) and if https exists then there will be a re-direct to port-443.

this redirect is certainly caused by the server's response to the initial http request.

After that, it seems that browsers will remember the next time you hit that domain to automatically go to port-443 (until or unless you clear the browser cache I guess). There seems to be some add-ons that alter behavior so port-443 is the default first-access.

this may be HSTS in action:
HTTP Strict Transport Security [https.cio.gov]

[SumGuy]

Regarding HSTS, I may have more to say or ask about it later (first impression is that you're simply replacing the http->https redirect instruction with something else so saying that you're "activating" HSTS on a given site/server seems to be a strange way to put it) but I found the following interesting:

=====
To solve this problem, the Chrome security team created an “HSTS preload list”: a list of domains baked into Chrome that get Strict Transport Security enabled automatically, even for the first visit. Firefox, Safari, Opera, and Edge also incorporate Chrome’s HSTS preload list, making this feature shared across major browsers.

[chromium.googlesource.com...]
=====

For one thing, again I don't know why they had to invent a fancy way or fancy terminology to say that maybe browsers should try https first instead of http when a user enters a url (without http or https) into a browser address bar.

Second thing - I'm not able to bring up the above googlesource.com page. Eventually I get the google robot giving me a 502 (bad gateway) error.

How long has this hsts thing been around, and is it widely adopted?

[SumGuy]

> Chrome security team created an “HSTS preload list”: a list of domains baked into Chrome

Ok, I've seen the list, and I can't believe how full of garbage it is. Talk about browser-bloat.

[lucy24]

maybe browsers should try https first instead of http when a user enters a url (without http or https) into a browser address bar

Have you ever tried requesting https://example.com for a site that you know to be http? If the server isn't listening on port 443, it will take a very, very long time before the browser comes back with a “couldn’t get through” message. Worse, if it is listening on port 443, but the individual site happens not to be https, the human user will get a message from their browser warning that the site isn't configured correctly. The identical message is displayed, regardless of whether the error is at the site's end--expired certificate--or the user's end--making an invalid request.

Requesting http for an https site leads to one extra round trip, probably not even noticeable to the human user.

Requesting https for an http site leads to de facto failure.

Like many problems, this one will eventually go away. Five or ten years from now, any site that is still http is probably a site that hasn't been maintained in years and doesn't deserve visitors. But that time isn't yet.

[SumGuy]

> Requesting https for an http site leads to de facto failure.

So we're going to build a list into all browsers of domains that are ok to hit first on https. Is that really desirable? Do you know how large that's going to be?

And what about this: Google and bing now know that my site / domain is both http and https. How long will it take for them to put up https SER links - assuming I do nothing else (ie create redirect links from http to https for example)?

[lucy24]

So we're going to build a list into all browsers of domains that are ok to hit first on https

No, we're going to continue requesting http by default. For the time being, that is the only viable option.

my site / domain is both http and https

Why? Are you trying to confuse the user--and the search engine that supplies you with users?

I cannot for the life of me conceive of any reason* why an https site would choose not to redirect http requests. Ordinarily that's one of the integral components of a site's move to https. (There's a checklist that keyplyr or someone like him posts every couple of weeks. I'm quite sure redirecting is on it.)


* Yes, all right, one possible reason: A site's users belong to a demographic that is stuck with archaic technology, such that a substantial proportion of them would be genuinely unable to access an https site. But that is an exceedingly small group.

[SumGuy]

> > So we're going to build a list into all browsers of domains that are ok to hit first on https
>
> No, we're going to continue requesting http by default. For the time being, that is the only viable option.

Do you not know what this is:

> Chrome security team created an “HSTS preload list”: a list of domains baked into Chrome

That is a list of domains that the chrome browser (and apparently others) will have "baked into" their code, so that when you type the domain into an address bar, or even click on an http link, the browser will go straight to the https site.

> > my site / domain is both http and https
>
> Why? Are you trying to confuse the user--and the search engine that supplies you with users?

As a result of being concerned that browsers were (now) throwing up warnings when users hit http sites, and that google may be playing games with ranking of http-only sites/domains, I began to investigate getting https up and running on our server (nt4-IIS4). After discovering that current SSL certificates/keys were probably not going to work on IIS4, I installed something called Abyss web server, and I'm making sure that our current html files and such are copied over to the Abyss side and that it works as intended, including port-forwarding 443 to our NT4 server. Upon doing that, it wasn't more than 12 hours before google and bing hit the https site and began crawling it. They've been doing that for a week now, but apart from some chinese bots there hasn't been any "organic" hits to the https site.

I'm curious as to when (or if) google will start giving https SER since it now knows they exist and are functional. Anyone typing "https://www.mydomain.com" into their browser will get the https site. No redirection from the http site required.

[phranque]

I'm curious as to when (or if) google will start giving https SER .... No redirection from the http site required.

...unless you want to insure that google starts indexing your https: urls.
this is probably the strongest signal you can give to google about your preferred scheme/protocol.

btw are you linking internally to your http: urls or your https: urls?
this is another strong signal as far as google is concerned.

are you supplying a sitemap file?
if so are you listing https: urls?