I inherited some cold-fusion web servers at my organization from another sysadmin who is no longer with the organization. I intend to build some new cold-fusion 2018 web servers, and am planning for that now.
The previous sysadmin assigned one unique IP address per website. He only filled out the hostname for the port 80 binding, and no hostname for the port 443 binding on each site. This strategy uses a LOT of IP addresses. I am trying to be efficient, and looking for a better way. I think I see how to do this, but am looking for confirmation, or any gotchas I may run into.
I have been doing some reading, it appears with IIS I can bind many websites (around 80 sites) to just one IP address (only assign one IP address to the server) using the standard ports (port 80 and 443). Since the same IP address and port numbers will be used on all 80 sites, the unique identifier would be the hostname I identify in the binding (url for the website). This should require the server to have a DNS entry (Host A record) to identify the server as is standard. Then each website would have it's own CNAME record pointing to the server's hostname (defined by the A record). In theory then, when someone navigates to the website, the hostname used in the URL will follow DNS to the webserver, which will identify the correct website to serve via the hostname in the binding. It appears I can bind multiple hostnames to a site using the same IP address and port number as well if I need to serve the same website to multiple URL's.
If I follow through with the new strategy I just defined, is there anything in cold-fusion that will break by doing it this way? Any gotchas?
Thanks for your time,
JD, your concept of consolidating/reclaiming ip addresses is sound And as for port 80 it's as simple as you say. For ssl/tls config (port 443), you may find additional struggles based on the type of ssl cert you have and perhaps the version of IIS (Windows) that you have. Let's see how it goes for you.
But you ask about impact on cf (which is spelled coldfusion btw), and there should be none.
The only thing I can think of readily is if your developer/s somehow put hard-coded references to the site ip addresses in the code. There's no reason they SHOUD have done that: I'm just saying they COULD have, and if so, then such code/functionality could now break. You could search your code for any references to some representative ip addresses (easily with good file search tools), or for variables like cgi.http_host and cgi.server_name.
Let us know how it goes.
Thanks for the information, I do have a follow up question for you.
For SSL on Port 443, I have 3 different certificates that I need to bind to my websites. I will be using IIS 10. I was planning to specify the correct certificate for each website on that website's binding for port 443. What type of struggles do you envision me having?
Our developers use DNS names in their code, so we should be OK there, but I did not think of that, thank you.
The problem with TLS here is that the web server can't use the Host header to figure out how to resolve things, like it can with plaintext HTTP. With TLS, your browser has to identify the IP address corresponding to the name of the secure site, then connect to the IP address while requesting that name. Most modern browsers support a feature called Server Name Indication (SNI) but if you have to support Windows XP clients or have to use older TLS or SSL protocol versions, you won't be able to use SNI. You really shouldn't have to use older TLS or SSL protocol versions for security reasons anyway, though.
If you can't support SNI, you will need to replace your existing certificates with a single certificate that contains all of the server names that you want to associate with HTTPS. This may be annoying and/or expensive depending on your CA.
Dave Watts, Fig Leaf Software
Thanks for the reply.
I just finished reading some Microsoft IIS docs on SNI. Supported since IIS 8, so I should be good there. Looks like modern browsers do indeed support it. I have no need to support Windows XP clients. Only planning to support TLS 1.2 anyway.
Thanks for the great information everyone!