-1

From what I read it seems that the certificate isn't a big deal since it's already public, and downloaded by every browser, however if someone gets hold of your key file, then you have an issue.

leeand00
  • 1,357
  • 1
  • 13
  • 21
  • 2
    Certificates are tied to a domain name. What you are asking is unclear. – schroeder Nov 17 '15 at 19:48
  • Okay a new server with the same domain name and hostname. – leeand00 Nov 17 '15 at 19:54
  • Why do you want to prevent that? What's the security angle? – schroeder Nov 17 '15 at 19:55
  • I guess it doesn't make sense. People can encrypt the message on the way in but nobody will be able to decrypt it without the private key...so it doesn't matter? – leeand00 Nov 17 '15 at 19:57
  • So I'm asking the wrong question.... :p – leeand00 Nov 17 '15 at 19:59
  • I think you need to review the basics of TLS\SSL – schroeder Nov 17 '15 at 20:00
  • Is this good? Or would you recommend something better? https://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#aboutcerts – leeand00 Nov 17 '15 at 20:02
  • 1
    That page (ssl_faq) is mostly details about implementing SSL/TLS with httpd, and assumes you already understand the concepts. Better to start with https://httpd.apache.org/docs/2.4/ssl/ssl_intro.html or our hometown canonical Q&As http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work . – dave_thompson_085 Nov 17 '15 at 23:01
  • 1
    @leeand00, have a look at this [answer](http://security.stackexchange.com/a/105590/13857) to a recent question about SSL and a stolen certificate. It's not quite the same as your question, although it should help you improve your Q, which I think you should do (for yourself and the community). – Andrew Philips Nov 18 '15 at 14:17

2 Answers2

2

Some of these answers aren't strictly correct.

Since the Certificate is the Public Key, it's Public and, therefore, can find its way to any machine. It just doesn't matter. And, yes, if someone gets hold of your Private Keys (via a recoverable key file), then that is almost certainly a problem.

However, it's a tiny bit more muddy and it seems.

Let's look at a Certificate, it contains a lot of information. Here's a subset:

  • An Encryption Key (used for network encryption)
  • A Signing Key (user for signing)
  • A web hosting (SSL) certificate which includes a Domain Name
  • Self-Signed Certificate portion or
  • Trust Chain up to some Root CA

A Certificate must be signed in order to be trusted by the client, otherwise transferring the certificate opens it up to a MITM attack. If self-signed, then the creator just signed its own cert with the Private portion of its Signing Key. If there's a Trust Chain, then there is at least one other inner Certificate (from a Certificate Authority) embedded in the outer Certificate and used to Sign the outer Certificate. There can be any number of intervening CAs (Zero or more), however, there's always a Root CA whose Certificate is self-signed.

Got all that?

Making it more confusing, the same Private Key can be used for Encryption and Signing, although it doesn't need to be. Actually, there can be multiple Encryption and Signing Keys (the Public portion) listed within the certificate. There's nothing that says there can be only one or one of each type.

Finally, there could a special type of Encryption Key used for SSL. This Key is special because it will contain a Domain Name that the browser checks to make sure it matches the domain to which it connected. That is, Certificate->Domain == Domain Connected?

This last type of certificate is the one folks are most familiar with as that's what produces the lock icon somewhere in the browser.

Is another machine with the Private Key bad?

In the case of a stolen Private Key for an SSL Certificate, well, it's not good, but it's not immediately awful. Even if you have the Private Key for a server, unless you can perform a DNS attack or you can run a man-in-the-middle attack or you can run an ARP spoofing attack or whatever, you can't fake that server for an SSL session connecting from a browser. Now, I wouldn't trust this situation lasting for very long. A stolen key store is bad and the certificate in question should be revoked. Strictly speaking, however, there's more to the SSL attack than just having the Private Key.

We do have another possible attack using the stolen Private Key. If a client is speaking with the real server and they are running TLS+RSA (that is, not TLS+RSA+Diffie Hellman or not some cipher suite that provides perfect forward secrecy), Eve the Eavesdropper can watch the exchange, decrypt the session using her copy of the Private Key and listen in on what transpires. So, an observation attack is possible.

There are some cases in which you'd want multiple machines to have the Private Keys.

Let's say your website has so much traffic you require multiple machines to handle it all. You might have a load balancer routing SSL connections to multiple back end machines, each of which would require a copy of the certificate and the Private Key in order to run the SSL handshake. You don't want to run a redirect to a new domain or subdomain (the browser may be configured to reject this for the SSL handshake), so each server needs to look like it's the real end deal.

There are SSL hardware accelerators that will run the SSL handshake (they contain the Cert and Keys) and then load balance and hand off the unencrypted TCP session to the backend servers. The TCP sessions aren't exposed because all of this happens on the protected side of some router/switch between the accelerator and the web servers.

Andrew Philips
  • 1,431
  • 8
  • 11
0

The certificate contains a public key for an asymmetric crypto algorithm (nearly always RSA). Anyone with the corresponding private key can use the certificate.

If the corresponding private key is stored on a general purpose computer than the administrator of said computer (or someone who has hacked into the computer and gained administrative powers) can make a copy of it and put it on another computer.

I believe there exist "hardware security modules" which can store a private key and allow it to be used for tls without revealing the actual key to the host system. I don't know the details though.

Peter Green
  • 4,968
  • 1
  • 22
  • 26