Certificate Authority (Public and Private Keys)

A simplified version ...
The secured website has a certificate that is issued by a Certificate Authority (CA.) Your browser looks in your PC's registry for the CA's "root" certificate. If it finds one, then the browser trusts any certificates issued by the CA. If it doesn't then it does not.

It's a similar concept to a driver's license which is issued by a known CA - the Dept of Motor Vehicles, which is a standard of identification accepted by most state and federal authorities. If you presented a driver's license that was issue by "Joe's Driving School" - an unknown CA - it would not be accepted.

The above is a bit oversimplified, as there may be one or more "intermediate" certificates involved.
The CA issues the intermediate certificate, and the server certificate is actually issued by the intermediate certificate.
This increases security, as the intermediate certificates can be more easily changed if necessary.

The simple approach is to use free https://LetsEncrypt.org certs which contain a trust chain in all major tools (like browsers).

This resolves many complex issues running your own Private CA + managing your own trust chain.

https://www.cloudflare.com/learning/ssl/how-does-ssl-work/ provides a good graphical overview of how certs work.

Will the CA issue Certificate to any Browser accessing the website  ?

Let's say when you go to secure web sites, you type https://xx.com
at this point the CA on the other end will issue a certificate to your browser ? if so how does the public/private key exchanges start?

The CA issues the web server certificate that is installed on the secured website. It doesn't issue anything to a browser. The CA's root certificate (that identifies the CA) is distributed/updated by Windows (for Windows operating systems) during Windows updates.

The private key remains on the web server being protected. It is only used to verify that the certificate issued by the CA to the web server is authentic.

there is a 3 way handshake

• Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use
• Decide on which cipher suites (see below) they will use
• Authenticate the identity of the server via the server’s public key and the SSL certificate authority’s digital signature
• Generate session keys in order to use symmetric encryption after the handshake is complete

https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/ 

the ca is only used by the browser to verify the public key issued by the server was generated by the ca which is expected to perform checks regarding domain ownership.

as mentionned above, there can be intermediate authorities which will vouch for the below cert or previous authority and issue a public key which can be checked against the parent authority until the ca is reached.

the client-server encryption does not directly involve the ca

Let's say your company accesses secure website for business purposes.
your employees will open up the browser and type https://xx.com

when they reach the xx.com then what do they receive from it ? public key ? if so then what do they do with it?  will they send it back with some extra information ?
I wanted to understand the back and forth of information that goes between the browser and the web server before they trust each other.

The user enters https:/xxx.com
The user's browser requests that the web server identify itself.
The server sends the user's browser information about its SSL certificate (the public key).
The browser checks to see whether or not it trusts the issuer of the SSL certificate.
If it does, it sends a message to the web server that it's ok to start an encrypted session.
The browser and web server share an encryption key to be used for the session.
Encrypted data is then shared between the browser and the web server.
More info.

Thanks Sam,
<<The browser checks to see whether or not it trusts the issuer of the SSL certificate. >>

How does the Browser know that the server (issuer of the Certificate)  is a trusted source or not ?

 

Because it has as a Root Certificate for the issuer in its registry.
 

How did it get to the Register at the first place ?

For instance if I go to https://xx.com , the first time. I do not think  I have xx.com in the Registry yet.

xx.com is not in the registry ... The Certificate Authority who issued the certificate is.
So, for example, if your certificate was issued by DigiCert, it would link up to one of the following Trusted Root CA Certificates:

but how did DigitCert issue the Certificate at the first place.

Let 's make it simple
if you do an online purchase with amazone.com , ebay.com, neflix.com, target.com,etc......
you open the browser and connect to their secure websites ...how does your browser verify that is connecting to a real online store and not to faked one.
you can do a purchase over the computer, tablet , phone, etc..

<<The server sends the user's browser information about its SSL certificate (the public key).
The browser checks to see whether or not it trusts the issuer of the SSL certificate. >>

if you can explain your steps above, that might help
how does the browser know if the server  has sent wrong or right information about its SSL 

Let's use Amazon as an example. When you browse to https://www.amazon.com, the website presents the certificate on the left (1) to your browser:

The browser notes that the certificate is issued by (2) DigiCert Global CA G2, which it finds in the Intermediate Certification Authorities Store in your registry. That certificate (3) is issued by DigiCert Global Root G2 (4), and it finds THAT certificate in the Trusted Root Certification Authorities Store (below):
 
If either of the above (the Intermediate or the root) are not found, that's when you receive an error from your browser that the site certificate is not trusted.

the certificate authorities are provided with the operating system or browser, whichever provides the ssl library.

in windows, this is managed at the operating system level. certificate authorities are preset and possibly updated when applying relevant patches.

certificate authorities may chain one-another. if your browser does not know a CA, it will try to go up the chain until it finds a trusted or revoked one

Thank you skullnobrains 

I know Sam is trying to explain subsequent steps, before the initial one that  I have been trying to understand.
So in Windows the OS comes with know CAs installed

Now when you open your browser to do a purchase, ex: amazone.com
Amazone Server will send information about its SSL let s say it uses DigiCert Global CA G2 
The Browser will check with the Operating System if it has DigiCert Global CA G2  in its Certificates store. If it finds it then it will inform Amazon web server that it is ok, and Amazon web server can send its public key to your browser
Amazon will send its encrypted public key
your browser will use DigiCert Global CA G2  to decrypt the public key

almost there :
amazon does not care about the validation
the digicert certificate is not used to decrypt anything. just proove that digicert issued the certificate

the client says hello and send a random number ( client random )
amazon sends it's public key toghether with a random number ( server random )
the browser checks the key is valid and signed by a known authority or chain of authorities
amazon does not know or care about the validation. in case it fails, the browser will usually disconnect.
at this step, the client is sure it is talking with amazon
the ssl handshake goes on with the session keys exchange

the client encrypts another random secret with the server's public key
the server decrypts the secret using his private key
both the server and client generate symmetric session keys based on the secret and the random numbers

both the client and server encode their outgoing bytes with the symmetric key based on their random number and decode the incoming bytes with the remote end's key

in this article : https://www.entrustdatacard.com/pages/ssl

in Step 3 above :
will the client checks its Certificates store and see if it can find the same name of the certificate as the one mention on the Public Key that has been received from the Server ?
it also states that the client will send an encrypted key back to the server...  what kind of encrypted key ? its own public key? OR the public key received from the server with additional information on it ?
if it is adding information  to the public key it has received from the server, then it means that it is using the  CA in its own store to read information from the public key received from the server and adding information to it.

in Step 4 above:

Will the server Decrypt the public key received from the client using its own CA and adds information to it and send it back ?

it is a long thread. I will come back to this topic soon.
I got some grasp of it but not all
Thank you Guys !

Ok ... Have a great weekend ... stay safe!

hmm... mostly agreed except for that part :
The public key received from the server with additional information on it  

no key or certificate is ever modified by any party. those are digitally signed in order to prevent tampering.
unless i'm mistaken, that's actually the client's public key which the server will use to decrypt data sent by the client.

also, just to make it clear, neither of the session keys are signed by any third-party CA. the CA, revocation lists, and the likes  are only checked once during the initial handshake.