Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

6 Answers 6

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.

share|improve this answer
1  
... or the cert has multiple Subject Alternative Names valid for both hosts. The downside of sharing a cert between multiple hosts is that you also share their private key, which means that the key is compromised on one host, this affects both. This can also cause problems in terms who assigning responsibilities if the two machines are administered by different people. –  Bruno Jul 8 at 12:06
    
... and the users' browsers all support Subject Alternative Name. Not pre-2003 versions of Firefox (called Phoenix back then), Netscape, Opera or Safari, or Symbian 9.1 and earlier. Unlikely to be much of an issue these days, but it could be. –  Mike Scott Jul 8 at 12:18

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.

share|improve this answer

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.

They 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 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.

share|improve this answer

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:

  • abc.example.com
  • def.example.com
  • and so on as long as it's still *.example.com

But this one is more expensive compared to buying one directly for abc.example.com

share|improve this answer
2  
The term you want is domain rather than top level domain. A TLD is the very last part, such as .com. Also, to verify that you own the domain, the SSL company sends you an email (to an address such as postmaster), not the other way around. I can send anyone an email from an @gmail.com address but that doesn't prove I own gmail.com. You haven't actually answered the question either. The question is about buying two certificates for two servers. –  Ladadadada Jul 8 at 6:08
    
Oh yes. Sorry for the wrong TLD definition. @Ladadadada Thanks! –  zakiakhmad Jul 8 at 6:53

While there's nothing that technically stops you from installing a single cert to multiple hosts, there are licensing implications.

I recommend you read the fine print from your CA to ensure you are legal.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.