1

I know the general concept of how digital certificates works: e.g. server "signs" the message it wants to send to the client using his private key and sends along a message digest and on the receiving side client KNOWS the server public key and can verify that the message is indeed authentic (comes from server and not modified in transit) by using a decryption function and looking over the content of the message, do it's digest also and confirm that the actual message received is authentic.

The question is how can client tell that the server public key sent in the clear (I guess it's sent in the server hello response) is authentic ? I can understand that large CA have their certificates already installed on the client machine but if the server sends a certificate signed for example by Digicert how can I tell on client that that is indeed the case (maybe a MIM intercepted ssl handshake changing things) ?

enter image description here

To clarify things I've added the picture that describes the process by which client verifies that certificate signature is real. "When the browser receives the certificate, it checks the signing authority.If it is a public, well-respected signing authority, the browser will already know its public key (browsers ship with certificates of many signing authorities preinstalled), so it can verify the signature" Question: Signing authority public key has to be communicated somehow to the client (even if that CA is stored locally, how do you know what origin server uses ?). How is that process done ?

Ghita
  • 113
  • 4
  • 1
    In the figure you posted, the field "certificate issuer (signing authority)" is the identification of the CA that signed the certificate. CA=authority, issuer=signing authority=authority that signed this cert. As shown, the signature is verified using "signing authority's public key" which is the public key of that specific signing authority. – dave_thompson_085 Oct 01 '15 at 21:41

2 Answers2

3

I can understand that large CA have their certificates already installed on the client machine

That's it. It's just preloaded on the clients. No magic.

You need to get your trust anchors (root CA certificates) onto the clients BEFORE you can start reliable HTTPS. There is no way around that.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • when the server sends the certificate how it specifies in the clear that the certificate is signed by the authority with XXX public key ? And client can trust that key because after decryption using that key the certificate "makes sense" ? – Ghita Oct 01 '15 at 12:15
  • The "who signed me?" bit is simply part of each certificate. (And root CAs just put "i signed myself" there.) – StackzOfZtuff Oct 01 '15 at 12:24
  • Yes, but in order to extract the certificate information, certificate details I need to know first the signing authority public key ? how do I know that from the handshake exchange ? If it's sent on the clear (as I suspect) how can I trust it's authentic ? – Ghita Oct 01 '15 at 12:30
  • It's in the clear inside the certificates. But it's signed. Then you follow up the chain of trust and see if it leads you to a CA you like. If it leads to a CA that you don't like or no known CA at all, then you reject. Also if the signature is bad, then you reject as well. – StackzOfZtuff Oct 01 '15 at 12:52
  • When I say "extract certificate information" I mean you as a browser has to apply DecodeFunction(CA_publicKey, ciphertext) -> have certificate info in the clear now. But how do I obtain CA_publicKey ? Let's say for simplicity I actually have the CA certificate on my machine how do I know (from ssl handshake protocol) what CA_publicKey to use ? And if what I receive is sent (does protocol send the CA certificate in clear?) how do I know is authentic ? Once I know the CA public cert from a trusted source I can validate all other info. – Ghita Oct 01 '15 at 13:53
  • Updated the question with a diagram also – Ghita Oct 01 '15 at 14:06
  • 2
    @Ghita, I think your confusion may stem from a misconception that a digitally signed file is encrypted. It is not. A digitally signed file is a plaintext file with a signature appended to it. In the case of a self signed certificate, all the information required to validate the self-signed cert's signature is in the plaintext certificate. – jpheldson Oct 01 '15 at 19:10
  • To confuse things a bit, Windows and therefore IE/Edge and Chrome-Windows has changed to a mostly "pull" method: when a cert is received that uses a root not already installed, it checks with Redmond to see if that root is approved and if so installs it automatically. http://security.stackexchange.com/questions/81491/are-there-other-roots-of-trust-on-my-computer-aside-from-these-46-root-certifica . – dave_thompson_085 Oct 01 '15 at 21:59
1

I'm going to expand my comment into a real answer. I think the confusion here is linked to a misunderstanding of how digital signatures work.

Here is a simple process for creating a self signed certificate:

  1. Generate a public/private key pair.

  2. Create a file with my public key and my name that looks like:

    {public_key, my_name}

  3. Compute a cryptographic hash of that file (sha1 for example), and encrypt it with my private key:

    hash = sha1({public_key, my_name}) encrypted_hash = encrypt(hash, private_key)

  4. Append the encrypted hash to the end of the file.

At this point, the certificate should look something like:

{public_key, my_name, encrypted_hash}

To verify this certificate, a client follows these steps:

  1. Compute sha1 hash of certificate:

    test_hash = sha1({public_key, my_name})

  2. Compare this hash to the decrypted hash using public_key as the key:

    decrypted_hash = decrypt(encrypted_hash, public_key)

  3. If decrypted_hash = test_hash, the certificate is a valid self-signed certificate.

The big picture in this Wikipedia article really cleared things up for me when I was first trying to wrap my head around this stuff:

Wikipedia: Public key certificate

jpheldson
  • 151
  • 3
  • 1
    RSA signing is not "encrypt hash with private key" although part of it is similar which confuses many people; DSA and ECDSA signing do not resemble encryption at all, but provide a signature that cannot be forged, which is the definition of success for signing. Verifying a self-signed cert can be done, but is useless; it does not provide any assurance at all that the "my_name" is true. What does provide some value (although not always as much as thought) is that a cert for a server signed by a *CA* privatekey can be verified with the (known) *CA* publickey. – dave_thompson_085 Oct 01 '15 at 21:43
  • @dave_thompson_085 I don't know that "encrypt hash with private key" is a bad description of what is occurring, at least in the case of RSA. I'm not entirely sure what your definition of "encrypt" here is, but the hash is, to my knowledge, ciphered in a fashion that is reversible with the public key. In regard to validating the self-signed certificate, the value I believe this would add, is verifying the integrity of the certificate. I believe this would be a logical step before installing a certificate in a trust store. – jpheldson Oct 01 '15 at 22:04
  • @dave_thompson_085 in the case of a "real, non self signed" certificate the CA signer name is included and also it's public key in the certificate response ? – Ghita Oct 02 '15 at 04:55
  • @Ghita, to be clear, self signed certificates are "real" in the sense that the root CA certificates are all self signed. A certificate for a non CA entity A will look something like: {public_key_A, name_A, name_B, signatureOf_B) where B is either a root CA or an intermediate CA. If it's an intermediate CA, they will have their own certificate signed by the next CA (root or intermediate) in the chain. – jpheldson Oct 02 '15 at 12:36
  • @Ghita, it may also be noted that sometimes a server will distribute the intermediate certificates along with it's own to help the client build the trust chain back to one of the roots in it's store. – jpheldson Oct 02 '15 at 12:44