0

I'm trying to understand how SSL/TLS certificates work, but I'm missing something. I have obtained my current understanding from this website: http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html.

I've also seen this post: How do the processes for digital certificates, signatures and ssl work?

After reviewing both links for the nth time, the real mystery for me surrounds how the client verifies the server's certificate.

Here's my understanding of the steps:

1. Certificate Authority (CA) gives an encrypted root certificate to a server.
2.a. Server gives client a locally encrypted certificate and a public key.
2.b. Server gives client a root certificate which is decrypted with the public key already on the client's computer.
3. Client uses public keys to decrypt certificates.
4. Certificates contains information that satisfies client of servers authenticity.

I'm probably missing some critical information at each step, and probably also missing steps here. Assume I am the client. Here are my questions:

Q0. How do I (the client) know that I should use the given public key to decrypt the certificate? In other words, if an imposter can obtain a decrypted certificate (which--can't anyone who visits the server get these?); can the imposter encrypt the certificate with his own private key, and give me a new public key?

In this case, I think I should be able to decrypt the certificate. The clear text check may simply not work. But, can the imposter edit the clear-text to make my browser happy?

Q1. What if an imposter simply forwarded me the encrypted certificate? I would decrypt it with a real public key. There's probably something in my step 4 that I'm missing.

In this case, again the clear-text certificate must have some info that reveals it is bad. What is this info?

Q2. Is there clear text information in the decrypted certificate validates that I (the client) am connected to the server I want to connect to? I'm sure the certificate should say something like "from stackoverflow.com". Since this is done by a computer, I assume there are many comparisons done?

Q2.a How do I (the client) know that I have the correct certificate? For example, if stackoverflow.com sent me a certificate for Amazon.com, how would the browser detect a problem if (for malicious reasons) the certificate decrypted?

Community
  • 1
Java Addict
  • 11
  • 2
  • The problem is that you appearently have trouble with the basics of asymmetric encryption or at least the terminology. This makes it almost impossible to understand your question and have a discussion. You constantly talk about “encrypting” and “decrypting”, but the certificate verification procedure has absolutely nothing to do with encryption. It's about *signatures* and verifying them. But even if I replace the incorrect terms in my mind, large parts of your text just don't make sense. It might be a good idea to read up on the basics and then make a new attempt. – Fleche Jul 29 '14 at 20:28

1 Answers1

6

First step: forget all about encryption. There is no encryption in certificates. There are digital signatures. Digital signature algorithms, when first invented and published (in the late 1970s), where unfortunately described as "encryption with the private key", which is a flawed analogy, that does not actually work, and entails a heavy dose of confusion. Just say no. Speak of signature.

A signature is a piece of data that is:

  • computed over a given sequence of bytes;
  • requires a private key;
  • can be verified by using the corresponding public key.

Certificates are signed by Certification Authorities. By that signature, the CA says: "I, the CA, guarantee that the contents of that certificate are correct". What does a certificate contain ? Mainly an identity and a public key. What the CA asserts is that the public key (in the certificate) is really owned by the entity whose identity is in the certificate.

The idea is that, when you (the client) connect to a SSL server the server sends its certificate back to you. You can then verify the signature on that certificate, thereby gaining some trust in the identity/public key binding that the certificate embodies. You also check that the name in the certificate is what you expect (the name of the server you are trying to talk to). Once these two verifications have been performed, you have some reasonable assurance that the public key in the certificate is really the public key of the genuine server. The rest of SSL uses that public key for all the SSL crypto.

This process works only if you already know the CA public key. You could learn it with another certificate (containing the CA public key and signed by some über-CA); this is common (that's the concept of intermediate CA) but it only moves the problem around. You have to know, a priori, some CA public key at some point. Bill Gates, in His infinite Wisdom, saw it fit to include a hundred or so "root CA" public key in Windows / Internet Explorer, so that your trust may start somewhere.

That's the gist of it: a certificate represents a binding between an identity and a public key, and is signed by some CA; you verify the binding by verifying the signature, which requires use of the CA public key; you either know the CA public key by an Act of Bill Gates, or through another certificate, and so on. All this is done by Transport Layer Security (TLS)/SSL clients.

The rest is just technical (and complex). You may start with the Wikipedia page, which is as good (and as bad) a starting point as anything else on that subject.

Nagev
  • 103
  • 3
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955