How many SSL certificates needed for load balanced web servers - ssl

I have 3 servers. 1 is IIS-ARR load balancer. 2 servers are IIS web servers with my website hosted. I want to run the website on https. So how many SSL certificates are needed, which servers I have to create SSL CSR request and Which servers I have to install them.

I found a solution for this from another query. I need to use a certificate with Subject Alternate Names which is authorized for multiple domains.
Such a certificate could, once installed where the CSR was created in order to pair it with the private key, be exported as a bundle including the private key then imported on all involved servers.
So, just 1 certificate will solve the purpose.

Related

How to keep the SSL server certificate for verification in Cloud Foundry/Heroku?

I am developing an app to run in Cloud Foundry.
The app makes constant connections to a web service using https protocol.
The web service uses a pair of self-signed certificate created by openssl.
As there is no DNS setup, I am using IP address as the Common Name(CN) in the ssl certificate.
However, the web service IP address varies from time to time. The ssl certificate has to be re-generated each time.
In order for the app to connect, it needs to trust the SSL certificate so I have been packaging the public key for the web service’s SSL cert as a file with my app.
The problem is that I have to re-upload the app to Cloud Foundry once the public key of the SSL cert changes.
Here are some possible solutions:
Register a host name in DNS. In that case, the certificate is only bound to host name. (Might not be possible cos of the budget. )
Create a private CA and issue certificates from the CA, then install the CA as the trusted CA on the client. It is feasible and a common way for internal services. However, what if the app is pushed to the CF? How can we configure the node for the certs?
Disable the SSL server authentication. Not sure whether it would put the app at risk if the authentication is skipped. For the time being, the app pulls data from the web service.
I've been thinking of keeping the public key in the database. In that case, I don't need to re-upload the app to make it take effect. But I am not sure whether it is a safe way.
Question
I am seeking for a common and safe way to keep the SSL server cert in a Cloud Foundry env. Are any of the above solutions viable? If not, is there any other CF preferred ways?
Thank you
This is a bit old, but in case this helps...
Did you try to generate your server SSL certificate with whatever hostname (even "localhost"). As you are uploading this certificate in your application (i.e. to "blindly" trust it), I think that it could work and this would avoid dependencies with your IP address.

Understanding ssl certificates

I am having a bit of trouble understanding how many ssl certificates I should get under specific conditions:
I have two pages the user is supposed to use (index and main) and all other scripts users don't access in the front end (e.g. uploadFile.php).
I have socket.io implemented in port x which I want to run over https protocol.
How many ssl certificates should I get under these conditions to assure secure data traffic? (is the data from all other php scripts still secure if index and main have ssl?)
SSL cert is issued for a specific DNS name. So if you run your PHP and Socket.io applications on the same domain, one cert is surely enough to secure both.
If you run your app on two different domains, you need to (a) use two separate regular certificates, or (b) have one SAN certificate (it secures multiple DNS names).
Also there is a wildcard certificate, it secures all direct subdomains of specified domain (*.some-site.com). It can be combined with SAN feature, so it can secure base domain some-site.com and direct subdomains as well.
IF your website is accessed via different website on https , then your website and the website through which its accessed needs to have their separate SSL certificate.
If your website does not have an ssl certificate , the connection will be dropped when your website link is accessed via other website.

SSL Certificates for just API or do clients need them to?

I have a RESTFul API that I want to secure using SSL Certs. If I were to get some SSL certificates, would I need separate ones for each of my web clients that use my API or would the API be the only thing that needs the certificate?
The SSL certificate is installed on your web server hosting your REST API. The clients don't need to have a certificate to securely exchange data with your server.
Think about all the e-banking/e-shopping sites that you probably use. You don't specifically install any certificates on your computer to be able to use them. As long as you trust the certification authority that issued the certificates to those websites (handled by your computer transparently), your computer can connect to them over SSL.
So, as long as your own server's SSL certificate is valid and issued by a trusted certification authority, your clients will be able to connect securely over SSL without needing separate certificates.
SSL Certificates are for Web Server. You install them in your Web Server. Certificates are matched to your domain. They have nothing to do with the clients. Any client can access your server if you have a valid certificate.
I think you have multiple Resful API's.
Now you need not have separate Certificates for API's since Certificates are matched to your server's domain and not to the API's you host. You can have any number of API's and Clients connected to your server using a SSL Certifcate.

Single Site w/ shared SSL Certs on Azure

We would like to setup an application on Windows Azure at abc.cloudapp.net which would have a CNAME record for www.mydomain.com pointing to it and then allow clients to do the same. Our application would then look at the requested URL and then pull out relevant data based on the requested domain (abc.theirdomain.com or www.theirotherdomain.com).
Our initial tests show that this should work, however the problem lies in that we need the site to be secure. So we'd like clients to be able to setup shared SSL certs with us that we would upload to our Azure subscription that then allowed them to create a CNAME record (abc.theirdomain.com or www.theirotherdomain.com) that points to either www.mydomain.com or abc.cloudapp.net.
Is this possible?
Edit: I'm not sure if this is the same question as Azure web role - Multiple ssl certs pointing to a single endpoint.
We've used a multi-domain certificate in this situation - see http://www.comodo.com/business-security/digital-certificates/multi-domain-ssl.php for details. This will work for up to 100 different top-level domains.
The problem with a multi-domain certificate is that it is more expensive than a "normal" certificate and that every time you add a new domain, you will have to deploy a new package with the updated certificate.
On the other hand, you could have multiple SSL certificates (one for each domain) and then the answer you seek is here Azure web role - Multiple ssl certs pointing to a single endpoint.
No, I don't think your setup would be possible with a single SSL cert. In general, SSL certs are tied to the hostname (e.g. foo.domain.com and foo.domain2.com need different certs). However, you can purchase a wildcard SSL cert that will help if you use the same root domain, but different subdomains (e.g. foo.domain.com and foo2.domain.com can share a wildcard cert).
So, in your case, since you are allowing different root domains, then you need a different SSL cert for each. If instead you choose to allow different sub-domains on same root domain, you can get away with the wildcard cert.

SSO and SSL Certificates

I was ask to use a different SSL certificate for my SSO web service and a different SSL certificate for my website.
Why would I need a different SSL certificate when both the website and webservice are under the same IIS?
Usually certificates are issued to a particular domain. If your website and webservice are on different sub domains then you would use a different certificate for each.
Alternatively you can obtain wildcarded certificates (ie. *.yourdomain.com) but these tend to be much more expensive.