0

I am a project manager and is touching on an IT project consisting of the usual 3 tier - web/client - middleware - database.

In this case, I have an web server and needs to implement SSL certification. Though this is not in my scope, but I felt understanding the entire process will be beneficial to everybody.

I understand symmetric and public key encryption concept.

I understand digital signature concept.

But I can't place the whole picture together. Hence, please excuse me for the lengthy post.

Here it goes,

  1. The whole reason of HTTP/SSL certification, if I am not wrong is for 2 purposes

    • encryption (so data between client and webserver are secured)
    • authentication (so that "abc.com" is indeed "abc.com")

Right?

In order to proof "abc.com" is "abc.com", "abc.com" have to apply for a certificate from a Certificate Authority - which will do background checks etc. before issuing the certificate.

The certificate is then signed by CA.

  1. Over here, since the certificate is digitally signed by the CA. So I believe, two things will be sent to the client when the client access the browser

    • the certificate itself
    • hash and digital signature of the certificate.

Right?

  1. Since the certificate is signed by the CA (e.g. Verisign), it is encrypted by its private key. So where do I obtain Verisign public key?
  1. Assuming the public key is obtained, the digital signature is then decrypted and the hash value matched with the hash value of the certificate,

The public key inside the certificate (which belongs to the "abc.com") will then be used by the client to encrypt its data to be sent to "abc.com".

Right?

  1. This "data" is actually part of a negotiation between the client and the webserver for the use of a symmetric key use for subsequent communication.

Once the symmetric key is established on both sides, subsequent communication will be encrypted using that symmetric key and not the public key inside the cert.

Right?

Am I getting this on the high level or am I totally way off?

(added)

Thinking back, When we create self-signed cert, how do we "pass" the public key to the client or whoever that is accessing the to our website ? if the public key of the signature is not given to the client -> is this the scenario whereby a popup will appear on the client browser and ask whether "to trust" the website ?

Noob
  • 501
  • 1
  • 7
  • 11
  • re #2 the certificate contains information about the "subject" (for an HTTPS server, the server name(s) and publickey), plus some additional data like validity period and CA name, plus the signature by the CA, all in a single blob of data. For the rest, I concur with @Stackz reference to His Exalted Beariness at #20803. – dave_thompson_085 Jan 18 '16 at 03:34

2 Answers2

4

  1. A: Authentication only. You can still do "null" encryption afterwards, if you like. But if you do non-null encryption, then you'll have an idea of who with you're doing that. That's the authentication part. -- There used to be a time when SGC, Server-Gated-Cryptography, was a thing. An extra bit in the certificate would either allow or disallow any decent encryption stronger than 40 bits "export" size. Nowadays this no longer exists and certificates have NO say in the strength or sort of encryption that happens.

  2. two things will be send to the client when the client access the browser

    Nearly. The server is required to send its own cert and the chain of signing certificates. All the way up to a root CA. (Sending the root CA cert itself is optional, and you're allowed to leave it out.)

  3. So where do i obtain Verisign public key ?

    On their website. But the actual idea is that you don't need to do this. The idea is that any client software that you use already includes "trustworthy" Certification Authorities certificates. Microsoft, Mozilla, Apple, Java all maintain their own "certificate trust store"s.

  4. Sort of. The signature is verified (not "decrypted") and you use the public key from inside the certificate.

  5. Close enough.

Further reading:

Community
  • 1
StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
  • thanks for the wonderful explanation for 1) you mentioned the reason for using http/ssl is for authentication only, but isnt the public key inside the cert use for encryption ? for 4) i thought a digital signature is the encryption of the hash(cert) using the CA private key ? so by verifying the signature, you have to decrypt using the CA public key ? why is it not a decryption ? – Noob Jan 18 '16 at 12:56
  • Re #1: Yes. But you only use that public key to exchange a SESSION KEY. And then that session is used for the actual bulk encryption. Re #4 They look similar, but [signing is not encryption](https://crypto.stackexchange.com/questions/15997/is-rsa-encryption-of-a-cryptographic-hash-with-a-private-key-the-same-as-signatu). – StackzOfZtuff Jan 18 '16 at 13:17
  • wonderful, the link just make my jaw drop. but yes, you have make understand the general concept. thanks a million. – Noob Jan 18 '16 at 16:45
  • sorry, i have added/edited the original post for 1 last question to wrap this up. please let me know your view. – Noob Jan 18 '16 at 16:46
0

To answer Q3, Verisign's public key (actually its root certificate) is included in your web browser, along with a lot of other root certificates.

Mike Scott
  • 10,134
  • 1
  • 28
  • 35