The context:
I currently have a multitenant site (sub1.maindomain.com) and I am working on adding several other sites. Some of the new sites (sub2.maindomain.com, secdomain.com, ...) will probably also be multitenant.
I have certificates for each site I add, but only one IP address.
I'm working on Windows Server 2012, IIS 8.5.
The problem:
In order to allow multiple certificates I have to enable SNI in the https binding. Once I enable the SNI for the multitenant site (therefore editing the hostname) subdomains are no longer recognized (therefore no multitenancy).
Changing/Renaming/Restructuring the sub1.maindomain.com domain is not a real option, since it's being used by active clients for hosted pages among other things.
So far:
I am considering a wildcard certificate on which I can have the domains for all sites, (*.sub1.maindomain.com, *.maindomain.com, *.secdomain.com, ...) but I read that some browsers might have an issue with it and it is not recommended.
EDIT: It's been confirmed to me that I cannot consider the wildcard certificate option, mainly because of the price.
I have also tried using the Application Request Routing to solve the issue as described here but so far I it hasn't panned out.
From what I've tried so far I am either getting certificate errors in some or all of my sites, or "turning off" the multitenancy for the multitenant sites.
Any ideas on how to proceed?
Since we have a single multitenant app we allocated a second IP, given also that the cost is acceptable. The multitenant app is on one IP, the single tenant apps are all hosted on the other IP using the SNI feature to enable the use of multiple certificates.
Related
I've been investigating the possibility of migrating to using Let's Encrypt to maintain the SSL certificates we have in place for the various resources we use for our operations. We have the following resources using SSL certificates:
Main website (www.example.com / example.com) - Hosted and maintained by a 3rd party who also maintains the SSL certificate
Client portal website (client.example.com) - IIS site hosted and maintained by us on a server located in a remote data center
FTP server (ftp.example.com) - WS_FTP Server hosted and maintained by us on a server located in a remote data center
Hardware firewall (firewall.example.com) - Local security appliance for our internal network
Remote Desktop Gateway (rd.example.com) - RDP server hosted and maintained by us on a server located locally
As indicated above, the SSL certificate for the main website (www) is maintained by the 3rd-party host, so I don't generally mess with that one. However, as you can tell, the DNS records for each of these endpoints point to a variety of different IP addresses. This is where my inexperience with the overall process of issuing and deploying SSL certificates has me a bit confused.
First of all, since I don't manage or maintain the main website, I'm currently manually generating the CSR's for each of the endpoints from the server/service that provides the endpoint - one from the IIS server, a different one from the RDP server, another from the WS_FTP server, and one from the hardware firewall. The manual process, while not excessively time-consuming, still requires me to go through several steps with different server systems requiring different processes.
I've considered using one of Let's Encrypt's free wildcard SSL certificates to cover all four of these endpoints (*.example.com), but I don't want to "interfere" with what our main website host is doing on that end. I realize the actual certificate itself is presented by the server to which the client is connecting, so it shouldn't matter (right?), but I'd probably still be more comfortable with individual SSL certificates for each of the subdomain endpoints.
So, I've been working on building an application using the Certes ACME client library in an attempt to automatically handle the entire SSL process from CSR to deployment. However, I've run into a few snags:
The firewall is secured against connections on port 80, so I wouldn't be able to serve up the HTTP-01 validation file for that subdomain (fw.example.com) on the device itself. The same is true for the FTP server's subdomain (ftp.example.com).
My DNS is hosted with a provider that does not currently offer an API (they say they're working on one), so I can't automate the process of the DNS-01 validation by writing the TXT record to the zone file.
I found the TLS-ALPN-01 validation method, but I'm not sure whether or not this is appropriate for the use case I'm trying to implement. According to the description of this method from Let's encrypt (emphasis mine):
This challenge is not suitable for most people. It is best suited to authors of TLS-terminating reverse proxies that want to perform host-based validation like HTTP-01, but want to do it entirely at the TLS layer in order to separate concerns. Right now that mainly means large hosting providers, but mainstream web servers like Apache and Nginx could someday implement this (and Caddy already does).
Pros:
It works if port 80 is unavailable to you.
It can be performed purely at the TLS layer.
Cons:
It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon.
Like HTTP-01, if you have multiple servers they need to all answer with the same content.
This method cannot be used to validate wildcard domains.
So, based on my research so far and my environment, my three biggest questions are these:
Would the TLS-ALPN-01 validation method be an effective - or even available - option for generating the individual SSL certificates for each subdomain? Since the firewall and FTP server cannot currently serve up the appropriate files on port 80, I don't see any way to use the HTTP-01 validation for these subdomains. Not being able to use an API to automate a DNS-01 validation would make that method generally more trouble than it's worth. While I could probably do the HTTP-01 validation for the client portal - and maybe the RDP server (I haven't gotten that far in my research yet) - I'd still be left with handling the other two subdomains manually.
Would I be better off trying to do a wildcard certificate for the subdomains? Other than "simplifying" the process by reducing the number of SSL certificates that need to be issued, is there any inherent benefit to going this route versus using individual certificates for each subdomain? Since the main site is hosted/managed by a 3rd-party and (again) I can't currently use an API to automate a DNS-01 validation, I suppose I would need to use an HTTP-01 validation. Based on my understanding, that means that I would need to get access/permission to create the response file, along with the appropriate directories on that server.
Just to be certain, is there any chance of causing some sort of "conflict" if I were to generate/deploy a wildcard certificate to the subdomains while the main website still used its own SSL certificate for the www? Again, I wouldn't think that to be the case, but I want to do my best to avoid introducing more complexity and/or problems into the situation.
I've responded to your related question on https://community.certifytheweb.com/t/tls-alpn-01-validation/1444/2 but the answer is to use DNS validation and my suggestion is to use Certify DNS (https://docs.certifytheweb.com/docs/dns/providers/certifydns), which is an alternative managed alternative cloud implementation of acme-dns (CNAME delegation of DNS challenge responses.
Certify DNS is compatible with most existing acme-dns clients so it can be used with acme-dns compatible clients as well as with Certify The Web (https://certifytheweb.com)
I have a nodeJS web application with Express running on a Digital Ocean droplet.The nodeJs application provides back-end API's. I have two react front-ends that utilise the API's with different domains. The front-ends can be hosted on the same server, but my developer tells me I should use another server to host the front-ends, such as cloudflare.
I have read that nginX can enable hosting multiple sites on the same server (i.e. host my front-ends on same server) but unsure if this is good practice as I then may not be able to use cloudflare.
In terms of security could someone tell me If I need nginx, and my options please?
Thanks
This is a way too open-ended question but I will try to answer it:
In terms of security could someone tell me If I need nginx, and my
options please?
You will need Nginx (or Apache) on any scenario. With one server or multiple. Using Express or not. Express is only an application framework to build routes. But you still need a service that will respond to network requests. This is what Nginx and Apache do. You could avoid using Nginx but then your users would have to make the request directly to the port where you started Express. For example: http://my-site.com:3000/welcome. In terms of security you would better hide the port number and use a Nginx's reverse proxy so that your users will only need to go to http://my-site.com/welcome.
my developer tells me I should use another server to host the
front-ends, such as cloudflare
Cloudflare does not offer hosting services as far as I know. It does offer CDN to host a few files but not a full site. You would need another Digial Ocean instance to do so. In a Cloudflare's forum post I found: "Cloudflare is not a host. Cloudflare’s basic service is a DNS provider, where you simply point to your existing host.".
I have read that nginX can enable hosting multiple sites on the same
server
Yes, Nginx (and Apache too) can host multiple sites. With different names or the same. As domains (www.my-backend.com, www.my-frontend.com) or subdomains (www.backend.my-site.com, www.my-site.com) in the same server.
... but unsure if this is good practice
Besides if it is a good or bad practice, I think it is very common. A few valid reasons to keep them in separated servers would be:
Because you want that if the front-end fails the back-end API continues to work.
Because you want to balance network traffic.
Because you want to keep them separated.
It is definitively not a bad practice if both applications are highly related.
I'm hosting a couple of sites on IIS 8.5 (Windows server 2012-R2).
These https sites are bound using a UCC SSL certificate from GoDaddy.
I created a new site on IIS and added binding using the "IIS Express SSL Certificate".
This caused the rest of my sites to stop responding to https requests.
I had to reassign the UCC SSL so my sites could work with HTTPS again, but I was wondering if anyone knows why this happens. Having these things happening in a production server is a nightmare so I was wondering if anyone could shed some light on this matter.
This usually happens when you use the same IP or port with all the HTTPS sites. if you want to use the same binding with the different hostname you could use the SNI(Server Name Indication).
Server Name Indication (SNI), which is a TLS extension to include a virtual domain as a part of SSL negotiation. What this effectively means is that the virtual domain name, or a hostname, can now be used to identify the network endpoint. In addition, a highly scalable web hosting store has been created to complement SNI. The result is that the secure site density is much higher on Windows Server 2012 and it is achieved with just one IP address.
It should be noted that in order for this feature to be used, your client browsers have to support SNI. Most modern browsers support SNI; however, Internet Explorer (of any version) on Windows XP does not support SNI.
When you assign the https binding to the site you just need to check the Require Server Name Indication checkbox.
I've been searching for a few hours to find a solution to my question/problem and whilst I believe that I have been able to clarify the reason why I have problems I have been unable to find a resolution.
I have one server which is hosting multiple web sites and a couple of these web sites are using SSL certificates. I have some shared images accessed by all sites and the way to stop the none-secure error on the SSL site was to serve those shared images from https://www.example-shared-image-server.com/images/imagename.jpg
This worked fine, until that is I noticed that by using Internet Explorer on Windows XP it is giving the message "There is a problem with this website's security certificate". What I then identified is that its because its picking up a certificate for a different domain on the server. Its all to do with hosting multiple sites on one server with SSL certificates.
Lets say I have four sites with only the first two with SSL certificates installed.
https://www.one.com
https://www.two.com
http://www.three.com
http://www.four.com
And lets not forget the following:
https://www.example-shared-image-server.com
So when accessing images from the above shared image URL it is actually bringing up https://www.one.com, hence the error.
So its seems to be something to do with IE not supporting SNI or SSL/TLS on Windows XP or Vista whereas it is on Win 7 and Win 8. This seems like an immediate ploy by M$ to force people to upgrade to more current operating systems. But the fact is that all other browsers support it.
But, what I have not been able to identify is what I can do about it. So I believe my question is, is it possible to host multiple web sites using SSL on the same server on different domains without causing IE to show errors. If not, what do other people do? And it yes, how do I configure it?
I have been on this for hours so if someone could help, I would really appreciate it.
Many thanks,
Rob
Windows XP's version of SChannel does not support SNI, which means that IE and other WinINET/WinHTTP-based applications do not support SNI on that platform.
http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx
SNI support was introduced in Windows Vista; if you're not seeing it work on that platform, it's likely that IE was reconfigured away from the defaults to enable SSL2. SSLv2-compatible handshakes do not carry TLS extensions like the SNI extension.
The only real workarounds here are to either:
Host each server on a different IP or port (so the server can select the certificate based on that information)
Use a certificate that contains multiple hostnames using the SubjectAltName field of the certificate
I'm investigating a little problem for my employer. My company runs a website under an SSL certificate for the domain www.domainone.net.nz (Yes, New Zealand)
However, there's been a high-level marketing decision to change our primary domain to www.domaintwo.co.nz.
So, easy, right? Buy a new SSL cert for www.domaintwo.co.nz and get it running on IIS. Easy.
However, we have a few WebServices published that need to be accessed over HTTPS - there's some systems in place out in the wild that are using https://www.domainone.net.nz/
I would like to run BOTH certs at the same time, and give our partners and clients that are using these WebServices a set timeframe (six months, say) to roll over to the new domain, before revoking the www.domainone.net.nz cert.
This is a bit fiddly to search for - I keep getting explanations of wildcard SSL domains, which wouldn't help in this particular case, as the central domain name has changed.
Is this possible under IIS? My asp.dll shows version 6.0.3790.4195
It's possible, if you have separate IP addresses for both sites, simply create two sites, one with each SSL certificate and point the directories for both sites to the same place.
But with a single website, no it's not possible
you should be able to do this as long as you have two different IP's one for each of the SSL Certs, you may have to set up two sites that point to the same location to get it working properly, but im not sure.