Where is private key when using SSL stored?

Question

Before using a ssl sertificate between a service that I will be hosting on my local network I will like to understand a little more about it. From reading on the internet this is how I understand how an SSL works.

1. client connects to the WCF service
2. the WCF service replies with it's public key and it's certificate
3. the client then verifies the certificate and encrypts his credentials with the public key
4. wcf service then decrypts that message with it's private key and validates the info
5. etc...

Know here are some things I do not understand:

• On step 4. where did the WCF service located it's private key?
• Why is the SSL certificate needed? from reading on the internet it is needed to verify that the Service is who I want it to be. That does not make sense to me because first I know the IP address of my service on my local network (I know who that service is). Pretend this is not the case I am on the internet and someone is trying to hack me. In that case then I believe that if I connect to their service instead of my real one there is nothing I could do because if you recall on step 2 the WCF service replied with the public key and the certificate (on plain text) that means that someone could grab that certificate and use it?
• If I use a SSL sertifiate and someone has access to the computer that is hosting the service he could somehow get the private key making my connections insecure?

Answer 1

First off, there are some steps missing in step three. What actually happens in step three is:

• the client verifies the certificate
• the client and the server send some messages back and forth whereby they negotiate what kind of secret key encryption they both can use
• the client creates a secret key for that encryption algorithm, encrypts the secret key with the server's public key and sends the encrypted secret key to the server.
• the server can now decrypt the secret key using their private key.
• the client and the server now agree on a secret key algorithm and they share the secret key. All communications are now encrypted and decrypted with the shared secret key.
• the client encrypts their credentials with the secret key ...

The reason for this is twofold. First, the math for public key crypto is much more expensive than the math for secret key crypto. The idea is to do that expensive math only once, to enable exchanging a shared secret. Second, the client knows the server's public key, but the client might not even have a public key, so how can the server send it a secret message? That's why they must agree on a shared secret key.

Anyway moving on to your questions:

Where does the service keep its private key?

On Windows it's in the certificate storage provided by the operating system. On other operating systems, I don't know.

Why is the certificate needed?

Suppose you want to buy my lawnmower with a credit card, but you are worried that I might actually be a crook. You would like to know my real name so that you can prosecute me if I start charging my trip to Vegas on your card.

So when we do the transaction, I show you a piece of paper that says "Eric Lippert claims that the owner of this piece of paper is Eric Lippert, signed, Eric Lippert". Do you believe me? If you already trust Eric Lippert then you don't need the piece of paper, and if you don't trust Eric Lippert, then the paper doesn't establish trust. This is a "self signed certificate".

Now, if I show you a piece of paper that says "VeriSign incorporated claims that the owner of this piece of paper is Eric Lippert, signed VeriSign", then the question is: do you trust VeriSign to have verified my identity? If you do, then this is evidence that the person you're talking to is who they claim to be.

That's the purpose of the cert. It establishes that a particular public key is really associated with a particular organization because it is signed by a mutually trusted third party called the certifying authority.

When you buy something with your credit card online, you presumably trust the web site to only make authorized charges to that card. The cert verifies that the public key you are going to use for encryption really is the public key of that web site, not some evil hacker's public key.

But the certificate with the public key is public, so couldn't someone grab the certificate and pretend to be the server?

Yes, but that doesn't help them unless they steal the private key, which is private. The person with someone else's cert cannot decrypt messages that were encrypted with the public key, so they're not going to be able to do the secret key exchange with the client! Even if they manage to trick the client, all they're going to get is a stream of bits encoded with a secret key of the client's choice, a secret key which the attacker cannot obtain without the private half of the certificate.

That means: if I allow access to my private key, someone can impersonate me, right?

Yes. The security of the entire system depends on the private key remaining private. That's why its called the private key. If an attacker gains access to your private key then they can impersonate you at will, so keep it secret, keep it safe. If your key is compromised there is a mechanism whereby the certificate can be revoked, but the damage will typically already be done.

Answer 2

Eric Lippert's answer is great, but I thought I'd add a few more details in response to a couple points:

• That does not make sense to me because first I know the IP address of my service on my local network (I know who that service is)

Yes, it is true that SSL verifying the server's identity is correct might not of much benefit if you are inside and intranet or on a trusted secure LAN. However, SSL or more correctly, TLS (Transport Layer Security), gives you an encrypted channel to communicate between your client and server. This means if anybody between your client and server is sniffing the network, they won't be able to read the message. TLS (SSL) is the most supported and simple way to achieve this.

• If I use a SSL sertifiate and someone has access to the computer that is hosting the service he could somehow get the private key making my connections insecure?

If someone has admin access to the server where the private key is stored (in the cert), and that person has malicious intent, then frankly, you lost a long time before that. When storing your certificates in the cert store, you can set specific permission about who is able to read, write, and modify the cert.

Hope this helps.