Understanding SSL

Solution 1:

An SSL identity is characterized by four parts:

1. A private key, which is not shared with anyone.

2. A public key, which you can share with anyone.

   The private and public key form a matched pair: anything you encrypt with one can be decrypted with the other, but you cannot decrypt something encrypted with the public key without the private key or vice versa. This is genuine mathematical magic.

3. Metadata attached to the public key that state who it is talking about. For a server key, this would identify the DNS name of the service that is being secured (among other things). Other data in here includes things like the intended uses (mainly used to limit the amount of damage that someone with a stolen certificate can do) and an expiry date (to limit how long a stolen certificate can be used for).

4. A digital signature on the combination of public key and metadata so that they can't be messed around with and so that someone else can know how much to trust the metadata. There are multiple ways to handle who does the signature:

   • Signing with the private key (from part 1, above); a self-signed certificate. Anyone can do this but it doesn't convey much trust (precisely because anyone can do this).
   • Getting a group of people who trust each other to vouch for you by signing the certificate; a web-of-trust (so called because the trust relationship is transitive and often symmetric as people sign each others certificates).
   • Getting a trusted third party to do the signing; a certificate authority (CA). The identity of the CA is guaranteed by another higher-level CA in a trust chain back to some root authority that “everyone” trusts (i.e., there's a list built into your SSL library, which it's possible to update at deployment time).

   There's no basic technical difference between the three types of authorities above, but the nature of the trust people put in them is extremely variable. The details of why this is would require a very long answer indeed!

Items 2–4 are what comprises the digital certificate.

When the client, B, starts the SSL protocol with the server, A, the server's digital certificate is communicated to B as part of the protocol. A's private key is not sent, but because B can successfully decrypt a message sent by the other end with the public key in the digital certificate, B can know that A has the private key that matches. B can then look at the metadata in the certificate and see that the other end claims to be A, and can examine the signature to see how much to trust that assertion; if the metadata is signed by an authority that B trusts (directly or indirectly) then B can trust that the other end has A's SSL identity. If that identity is the one that they were expecting (i.e., they wanted to talk to A: in practice, this is done by comparing the DNS name in the certificate with the name that they used when looking up the server address) then they can know that they have a secured communications channel: they're good to go.

B can't impersonate A with that information though: B doesn't get A's private key and so it would all fall apart at the first stage of verification. In order for some third party to impersonate B, they need to have (at least) two of:

• The private key. The owner of the identity needs to take care to stop this from happening, but it is ultimately in their hands.
• A trusted authority that makes false statements. There's occasional weaknesses here — a self-signed authority is never very trustworthy, a web of trust runs into problems because trust is an awkward thing to handle transitively, and some CAs are thoroughly unscrupulous and others too inclined to not exclude the scum — but mostly this works fairly well because most parties are keen to not cause problems, often for financial reasons.
• A way to poison DNS so that the target believes a different server is really the one being impersonated. Without DNSsec this is somewhat easy unfortunately, but this particular problem is being reduced.

As to your other questions…

Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?

While keys are fairly long, certificates are longer (for one thing, they include the signers public key anyway, which is typically the same length the key being signed). Hashing is part of the general algorithm for signing documents anyway because nobody wants to be restricted to signing only very short things. Given that the algorithm is required, it makes sense to use it for this purpose.

If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.

If you have several servers serving the same DNS name (there's many ways to do this, one of the simplest being round-robin DNS serving) you can put the same identity on each of them. This slightly reduces security, but only very slightly; it's still one service that just happens to be implemented by multiple servers. In theory you could give each one a different identity (though with the same name) but I can't think of any good reason for actually doing it; it's more likely to worry people than the alternative.

Also note that it's possible to have a certificate for more than one service name at once. There are two mechanisms for doing this (adding alternate names to the certificate or using a wildcard in the name in the certificate) but CAs tend to charge quite a lot for signing certificates with them in.

Solution 2:

My question is can't "B" just take this certificate, thus stealing the identity of "A" - which will allow them to authenticate as "A" to "C"

There's also a private part of the certificate that does not get transmitted (the private key). Without the private key, B cannot authenticate as A. Similarly, I know your StackOverflow username, but that doens't let me log in as you.

Why use hashing on the certificate if a part of it is already encrypted by the CA?

By doing it this way, anyone can verify that it was the CA who produced the hash, and not someone else. This proves that the certificate was produced by the CA, and thus, the "validation etc." was performed.

If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.

It depends on the particular case, but you will likely have identical certificates on each.

Solution 3:

First question: You are correct about what you get back from the CA, but you are missing part of what you need before you submit your request to the CA. You need (1) a certificate request, and (2) the corresponding private key. You do not send the private key as part of the request; you keep it secret on your server. Your signed certificate includes a copy of the corresponding public key. Before any client will believe that B "owns" the certificate, B has to prove it by using the secret key to sign a challenge sent by the client. B cannot do that without A's private key.

Second question: Typical public-key cryptography operates on fixed-size data (e.g., 2048 bits) and is somewhat computationally expensive. So in order to digitally sign an arbitrary-size document, the document is hashed down to a fixed-size block which is then encrypted with the private key.

Third question: You can use a single certificate on multiple servers; you just need the corresponding private key on all servers. (And of course the DNS name used to reach the server must match the CN in the certificate, or the client will likely balk. But having one DNS name refer to multiple servers is a common and simple means of load-balancing.)

Solution 4:

In general, yes, if the cert file gets stolen, nothing will stop someone from installing it on their server and suddenly assuming the stolen site's identity. However, unless the thief takes over control of the original site's DNS setup, any requests for the site's URL will still go to the original server, and the thief's server will stay idle.

It's the equivalent of building an exact duplicate of the Statue of Liberty in Antarctica with the expectation of stealing away New York's tourist revenue. Unless you start hacking every single tourist guide book and history textbook to replace "New York" with Antarctica, everyone'll still go to New York to see the real statue and the thief will just have a very big, green, complete idle icicle.

However, when you get a cert from a CA, the cert is password protected and cannot simply be installed in a webserver. Some places will remove the password so the webserver can restart itself without intervention. But a secure site will keep the password in place, which means that any server restarts will kill the site until someone gets to the admin console and enters the PW to decrypt the cert.