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?
Add a comment
|
6 Answers
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.
-
4... 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.– BrunoJul 8, 2014 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. Jul 8, 2014 at 12:18
-
I've certificate for *.abc.com and Can i use this certificate for dev.abc.com:9003 ? Dec 26, 2016 at 5:42
-
@RaviG. Technically, no problem. The port number makes no difference. Legally, read your certificate provider's terms & conditions. Dec 26, 2016 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
*.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.
-
Why / .How. is Google .doing to be secure. using multi-domains SSL certs if it's inherently less secure (which sounds true to me)?– lajarreJan 9, 2015 at 10:51
-
4
-
SAN certificates are sometimes called Multi-Domain certificates. Just a note for folks who may be familiar with the latter name.– flow2kDec 21, 2019 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. Apr 3, 2020 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.
answered Jul 8, 2014 at 13:49
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.comdef.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
-
2The 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 aspostmaster), not the other way around. I can send anyone an email from an@gmail.comaddress but that doesn't prove I owngmail.com. You haven't actually answered the question either. The question is about buying two certificates for two servers. Jul 8, 2014 at 6:08 -
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.
