I have a master server installed on AWS and the slave server installed on GoDaddy. How many SSL certificates do I need to buy? Can I use a single certificate for both?
If the master and slave use the same hostname, or you have a wildcard certificate and they both use subdomains of the same domain, then there is no technical reason why you can't use the same SSL certificate for both. But some SSL certificate issuers license them per server, and you may be in breach of your licence conditions.
A certificate is usable by a SSL server if the server name appears somewhere in the certificate (as a
dNSName within a Subject Alt Name extension, possibly with wildcards, as described in RFC 2818). The "server name" is what appears in the URL used by the clients. If the name in the URL does not appear in the certificate, the client browser will complain (loudly).
Massive certificate sharing is a thing. For instance, Google's SSL certificate contains all of the following names:
*.google.com *.android.com *.appengine.google.com *.cloud.google.com *.google-analytics.com *.google.ca *.google.cl *.google.co.in *.google.co.jp *.google.co.uk *.google.com.ar *.google.com.au *.google.com.br *.google.com.co *.google.com.mx *.google.com.tr *.google.com.vn *.google.de *.google.es *.google.fr *.google.hu *.google.it *.google.nl *.google.pl *.google.pt *.googleapis.cn *.googlecommerce.com *.googlevideo.com *.gstatic.com *.gvt1.com *.urchin.com *.url.google.com *.youtube-nocookie.com *.youtube.com *.youtubeeducation.com *.ytimg.com android.com g.co goo.gl google-analytics.com google.com googlecommerce.com urchin.com youtu.be youtube.com youtubeeducation.com
This hints at some extensive sharing of the same certificate, and that's Google, Overlord of the Internet, no less.
The critical part is not the certificate per se, but the private key. The certificate, properly said, contains the public key; the power of the server lies in the corresponding private key. If two servers "share" a certificate, then this means that both servers have access to the private key.
The recommended management method for private keys is to keep them local: the server itself is supposed to generate the key pair (the private and public keys), then send the public key to the CA (as part of a "certificate request") so that the CA may create (and sign) the certificate. The private key, thus, never leaves the server's entrails, and this is good, because the private key must be kept private.
When two servers contain the private key, then that key must have travelled at some point. Generically speaking, such key travel is sensitive and dangerous, and shall be done only with great care. Copying the key through SSH (i.e. a
scp command) ought to be safe. Alternatively, the private key may be packed with the certificate into a PKCS#12 archive (aka "PFX file") with password-based encryption: this will give decent protection for the key while it transits between the two servers IF the password has enough entropy (so use a big, fat and very random password).
It remains, though, that you will have two copies of the private key. Having server-specific private keys may make for (slightly) better damage containment in case of hostile server hijack.
This is quite a common practice. In fact, most large websites use load-balancing, which distributes the load of the site across multiple servers. There are two ways this can be done. The first is sharing the private key to every server that is going to host the site, the second is to use an SSL proxy that holds the private key on the edge of a private network of servers running the site (or possibly using alternate encrypted communication). Both have their strengths and weaknesses.
The key thing is that the certificate can only be used for the sites that it identifies itself as being valid for. The point of a certificate is to validate that a given server actually is the website with which you were trying to connect. This is done by a Certificate Authority (CA) verifying details about the owner of a private key and then issuing the certificate that basically says "these details are valid about the holder of the private key." Those details are the information about the operator and the name of the site or sites that they operate under that private key.
As others mentioned, it is also important to realize that some CAs put limitations on usage of certificates that they provide beyond the technical limitations, so it is important to verify that your intended usage is allowed by your CA or you may end up with your certificate being revoked.
As far as I know, when we want to buy SSL certificate, we need to verify that we are the legitimate owner of the domain. This is done by sending email to the SSL vendor using an email address from that very domain.
You can have *.example SSL certificate and use it as:
- and so on as long as it's still
But this one is more expensive compared to buying one directly for abc.example.com
The typical client will not notice a difference between the case where servers are using identical certificates and the case where servers are using two different certificates for the same domain.
However some clients more pedantic about security will produce a security warning, if they see two different certificates being used for the same domain name.
Such warnings can either be produced by the individual client caching the certificate for validation of later connections or by sharing the certificates in a p2p network.