# Can I use a single SSL cert on two different servers?

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.

• ... 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 '14 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 '14 at 12:18
• I've certificate for *.abc.com and Can i use this certificate for dev.abc.com:9003 ? – Nullpointer Dec 26 '16 at 5:42
• @RaviG. Technically, no problem. The port number makes no difference. Legally, read your certificate provider's terms & conditions. – Mike Scott Dec 26 '16 at 6:22

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
*.gstatic.com
*.gvt1.com
*.urchin.com
*.ytimg.com
android.com
g.co
goo.gl
urchin.com
youtu.be


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.

• Why / .How. is Google .doing to be secure. using multi-domains SSL certs if it's inherently less secure (which sounds true to me)? – lajarre Jan 9 '15 at 10:51
• +1 for "Google, Overlord of the Internet" :-) – Max Jun 9 '15 at 15:41
• SAN certificates are sometimes called Multi-Domain certificates. Just a note for folks who may be familiar with the latter name. – flow2k Dec 21 '19 at 1:28
• You're forgetting a few key points regarding google's services. Specifically, most of their servers host stateless user sessions and they spin up many servers that host the same service instance behind a load balancer. Under those circumstances all of those servers must share a single certificate. This is commonly referred to as a server cluster. Additionally, each server might host multiple service types, so all services hosted on the same clusters must share the same keys. This is partly due to secure DNS practices which require a certificate thumbprint to match what DNS shows. – Tikiman163 Apr 3 '20 at 18:15

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:

• 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

• 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 '14 at 6:08
• Oh yes. Sorry for the wrong TLD definition. @Ladadadada Thanks! – zakiakhmad Jul 8 '14 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.

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.

• Do you have any documentation to demonstrate that this is true? – Brad Sep 8 '18 at 21:29