Yeah fer real. This presentation was well done and easily understood. Now I have cleared up a lot of confusion previously in my mind. Thanks a million to David
05:31 digital certificate 06:31 trust 06:45 CA 06:52 A certificate authority validates the identity of the certificate holder 07:21self-signed certificate 08:55 user identification 12:37 self-signed certificate 15:14 testing 15:25 self-signed certificate , root certificate 17:18
I've been scrambling to figure out PKI the past few days and this video really helped me glue all the pieces together to solidify my knowledge of PKI. Thank you!!!
PKI and Certificates are always a tricky subject. This is so far THE best video I've seen going into depth on the subject. I would recommend this video to anyone in IT.
DONE thanks moved notes to onenote 6:25 digital certificate includes the public key only not the private key 8:30 how user/server gets a certificate from a certificate authority. The user generated their own public and private keys, they give that along with their identification to a certificate authority. This is called a certificate signing request CSR. The certificate authority then signs the certificate and gives it back to the user. 9:45 the certificate contains: public key only not private obviously, the CA identification and certificate owner/public key owner identification 10:30 how to make a CSR certificate signing request .key file contains key 12:41 self signed certificate A CA signing the certificate provides TRUST that the public key belongs to the person we think we are talking to. However, the certificate itself containing the public key that we use for encryption is what provides the encryption. Without a CA, we can still have encryption, but we can’t trust that when we connect to a server, the server/person responding is who they say they are (man in the middle attack). When the certificate is signed by a CA, we can be sure that they are who they say they are. Example, we think we are talking to Alice, but bob intercepts the message and sends us his own public key and says I am Alice. We think we are talking to Alice, but we are actually talking to bob. Our messages are still encrypted though but now bob can read them. A CA tells us hey this public key actually does belong to Alice so you can go ahead and use it to encrypt your message. 15:30 so just using a self signed certificate allows you to encrypt messages, but you are vulnerable to a man in the middle attack. To mitigate this, you need a CA to check with it “hey does this public key belong to person x”. You can set up a self signed CA (called a self signed CA because you usually non-root CAs are signed by another root CA - chain of trust) and create a root-certificate. You need to install the root certificate in every machine in your organization (like the hardcoded root CAs in your OS or web browser) 17:40 TLS flow
Along with great information presentation style, the presenter has a perfect knowledge reinforcement/voice/speed balance, which makes the info really sink in. No accent helps to stay focused as well.
Thanks a lot...i have been in IT field for a long time...many times i tried to understand keys, certificates etc... finally this video gave me a clear understanding ..thanks again.
Mr Crabbe. OMG. I am working on my degree in Cyber Security. I am currently taking my Cryptography class. Unfortunately the study material is absolute garbage. I have had to resort to outside teaching material to learn. Thank you for this video. It has helped me a ton.
Wow! Really great explanation. Really clears up a lot of questions I had about CA, Digital certs and how TLS uses asymmetric/symmetric encryption and why symmetric is better. All of of this knowledge in one place! Thank you.
Excellent explanation of a complex topic. Beginning the video with a review of symmetric and asymmetric encryption was super helpful and really paid off at the end. Thank you for producing and sharing this video!
Knowing something about the topic, I can understand what the poster is saying. I wonder if I had understood that without knowing anything. As a side note, the blue arrow 3. should not exist; nothing is conveyed from the server to the browser at that point.
19:36 wait so the security certificate and public key are sent from server to browser, and the browser uses an internal list of certifying authority to validate authority of the certificate? It doesn't make any calls to the certifying authority server (like in DNS)? Maybe I'm missing something but couldn't the server spoof a certificate to only look valid?
No.. your browser has access to the public certificate of the company in question (we'll call it ACME). So no server can spoof a certificate from ACME because a certificate from ACME is encrypted with ACME's private key. Only ACME has their own private key. Everyone has ACME's public key which is used to decrypt the certificate.
I was wondering how a 2-way communication is being established; since before you discussed symmetric session key, it seemed like only the server can receive encrypted data while the browser is simply the sender, not the receiver. Now I see. Thanks.
Hi Dave, nice video! One thing which is not fully clear to me: since CA signed certificates are public what does prevent a man in the middle from using the public certificate of for example google and pretending to be google?
The CA signs their certificate with their PRIVATE key, not public. Everyone has the CA's public key so everyone can decode the cert. and know it comes from the actual CA. Since no one has the CA's private key, no one can 'pretend' to be the CA. When a CA issues an SSL cert, it signs the cert with the CA PRIVATE key, which only they have. An imposter should never get any CA's private key and so can't issue a fake SSL cert. (in theory)
@@davecrabbe4579 your point is clear. My question was more on the fact that certificates seem to not guarantee that you're talking with a trusted party but only that the public key inside the certificate is the actual public key of the organization reported as being certified inside the certificate (So an imposter could not issue a fake SSL cert but he could still re use a valid SSL certificate pretending to be the organization being certified). If this was the case, certificates would be only effective in conjunction with TLS (in this case the imposter could not decrypt the messages inside the TLS session not having the private key). Correct?
Certificates actually contain much more information than I have listed here. And this is done to keep the concept simple. Actual SSL certificates contain the URL that they are assigned to. So if Evil.com steals NSCC.com's SSL cert, it can't put it on evil.com because the browser will block it. But I think your point is valid. If Dr Evil steals NSCC's cert, there is no point in sending it to someone as Dr Evil can't encrypt anything with NSCC's private key as they don't have it. But there are many, many more details on SSL than I have presented here.
@@davecrabbe4579 Great work you are doing to society !!!! [doubt] : server sends CA cert to client which contains server's public key. Now most browser's or hacker can have CA's public key which it can use to decrypt certificate and get server public key. Now in further communication he can act as client(identity theft) and send his own symmetric key encoded by server public which he stole. How is this prevented or am I missing something
@@shahzadhassan2518 yes.. you are missing something. All public keys are public. Anyone can get anyone else's public key. You don't decrypt with a public key, you only decrypt with a private key (in this scenario). A client takes the server's public key and encrypts a session key and sends back to the server. A hacker can send a different key back to the server, but the original client would not use that key and so no client private info is compromised. Anyone could potentially send a symmetric key (encrypted with a server's public key) back to the server, but then only info can be exchanged between those 2 parties. Other client's private info never enters into that session.
Hi sir !! If we make the request to any webserver and it share digital certificate along with its asymmetric public key. Then we can share data through assymetric session.. Then again why we are doing the symmetric session and sharing data through symmetric session??? Anyone pls let me know ... Thanks !!!
Asymmetric encryption is very slow.. it is just used to exchange the symmetric key.. Once both ends have the symmetric key, they then start their session with that; since it allows much faster communication.
How is the client/browser authenticated by the server? It seems that an imposter can pretend to be the client just not the server since server uses public key and client does not use public key. So, is client using a self-signed certificate (created by its private key, which can be decrypted by its (client's) public key) ? Also isn't Diffie-Hellman exchange the standard to produce a shared secret for symmetric encryption?
A self-signed cert is NEVER used for clients connecting to an unknown server. They are only used for internal testing and within an organization. They do not provide any guarantee that the certificate holder is who they say they are. Enter the Certificate Authority that validates an organization and creates an SSL certificate FOR THEM, that they can distribute. This SSL cert contains the server company's public key. This cert is encrypted with the CA's private key. The CA public key is in the public domain and any client can decrypt the cert to ensure it is a 'good' cert and the server they are attached to is who they say they are. So now I am attached to a 'good' server. The server uses its private key to encrypt a symmetric key. The client got the server's public key in the SSL cert and can get the symmetric key. Now both ends have a symmetric key to use for further communication. See the video on "Chain of Trust" as well.
Thank you I am reviewing the concept you explain it clearly. In your symmetric key exchange part which uses pub key to create session key, is this the diffie Hellman key exchange or is that different. This part I want to clarify.
Diffie Hellman used prime numbers to establish a shared secret between 2 parties. It is a precursor to using RSA(PKI) to exchange a key. This video does not describe the details of any particular system in use today. It is designed to show the common concepts that allow a shared key to be exchanged, using PKI. From this, one may look into the details of a current system and the fundamentals here will help you understand the more complete and complex system currently in use.
I am just describing some general charactistics of person certificates there. A certificate from ACME corporation contains information about ACME corp plus its public key. Root CA’s certificates are public information and often installed inside many OSes (Windows, macOS) and contain the public key of these root CA’s. This allows anyone to get a root CA’s public key so it can validate a digital signature from that organization.
No sure what you are asking.. The symmetric key is actually created by both ends, through information they exchange using the asymmetric protocol. Because only those 2 can exchange info using the asymmetric protocol, no one can intercept the symmetric key they generate. They both generate the same symmetric key and store it locally. Once this is done, all communication then uses the symmetric key encryption because it is faster.
When you create an account on your desktop computer it creates a private/public key pair for you. On Windows it is kept in the Certificate Store, in MacOS, in the KeyChain. These are tied to your user account. Since phones and iPads are single user devices, I assume it creates one when your device is first set up. It is done in the background and the user is unaware of it. There is also software apps that can create public/private key pairs and allow you to use those pairs with applications such as email. In this way you can exchange encrypted email with others. Since a person is not a well-known public institution, the person must send their public key to others to use. In email, when you sign and email, you are sending your public key to another. They use this key to encrypt a return email. In the return email, the other person can sign their email (which contains their public key). Now both of you have the public key of the other and can use that to encrypt mails to each other. You use your private keys to decrypt.
Can some explain to me how a client browser 'knows' that a certificate really comes from the intended webserver? What stops a hacker getting a signed certificate from a genuine webserver, copying it, then using it for a man-in-the-middle attack?
A few ways.. and I don't know all the protection schemes.. 1) an SSL certificate is only for a specific web site .. and so the browser will look at the web site name inside and compare it against the site the browser is attached to.. 2) the browser uses the web site's public cert to encrypt info back to the web site and only the original web site can decrypt with their private key.. To get around these issues, the man-in-the-middle must modify the SSL cert.. as soon as this happens, the checksum is altered and must also be changed. I believe the checksum is imbedded in the digital signature of the cert. Since the digital signature part is encrypted with the WEB SITE private key.. when the man-in-the-middle changes the checksum, they must also re-encrypt it with another private key.. as they don't have access to the original web site private key.. The browser uses its local certificate store to get public certs of those that sign SSL certs.. and so the browser gets the public cert of the original web site issuer and tries to decrypt the signature/checksum part. It can't and so knows the cert has been compromised and will not connect to that web site.
Undoubtedly, the best explanation of PKI and digital certificates. Thanks Dave!
I agree
I spent 2 hours in the class and couldn't think it through but it only took me 21 minutes to understand via this video. Thank you David!
Yeah fer real. This presentation was well done and easily understood. Now I have cleared up a lot of confusion previously in my mind. Thanks a million to David
05:31 digital certificate 06:31 trust 06:45 CA 06:52 A certificate authority validates the identity of the certificate holder 07:21self-signed certificate 08:55 user identification 12:37 self-signed certificate 15:14 testing 15:25 self-signed certificate , root certificate 17:18
I've been scrambling to figure out PKI the past few days and this video really helped me glue all the pieces together to solidify my knowledge of PKI. Thank you!!!
PKI and Certificates are always a tricky subject. This is so far THE best video I've seen going into depth on the subject. I would recommend this video to anyone in IT.
Thanks Charlie.. sometimes hard to find that balance of going into enough detail but not so much detail that the overall concept gets lost.
He is really an expert on this subject. Very well explained, understood the concept.
Great video! I love how you broke it down and walked through it nicely. Thank you.
very pleased with the explanation - i watched about 4 videos about digital certificates and this is the one which got me understanding it properly.
The best explanation video on the web. Thanks for creating this Dave.
DONE thanks moved notes to onenote
6:25 digital certificate includes the public key only not the private key
8:30 how user/server gets a certificate from a certificate authority. The user generated their own public and private keys, they give that along with their identification to a certificate authority. This is called a certificate signing request CSR. The certificate authority then signs the certificate and gives it back to the user.
9:45 the certificate contains: public key only not private obviously, the CA identification and certificate owner/public key owner identification
10:30 how to make a CSR certificate signing request
.key file contains key
12:41 self signed certificate
A CA signing the certificate provides TRUST that the public key belongs to the person we think we are talking to. However, the certificate itself containing the public key that we use for encryption is what provides the encryption. Without a CA, we can still have encryption, but we can’t trust that when we connect to a server, the server/person responding is who they say they are (man in the middle attack). When the certificate is signed by a CA, we can be sure that they are who they say they are.
Example, we think we are talking to Alice, but bob intercepts the message and sends us his own public key and says I am Alice. We think we are talking to Alice, but we are actually talking to bob. Our messages are still encrypted though but now bob can read them. A CA tells us hey this public key actually does belong to Alice so you can go ahead and use it to encrypt your message.
15:30 so just using a self signed certificate allows you to encrypt messages, but you are vulnerable to a man in the middle attack. To mitigate this, you need a CA to check with it “hey does this public key belong to person x”. You can set up a self signed CA (called a self signed CA because you usually non-root CAs are signed by another root CA - chain of trust) and create a root-certificate. You need to install the root certificate in every machine in your organization (like the hardcoded root CAs in your OS or web browser)
17:40 TLS flow
Along with great information presentation style, the presenter has a perfect knowledge reinforcement/voice/speed balance, which makes the info really sink in. No accent helps to stay focused as well.
Very good explanation and i like the pace of your speech and also some of the examples provided!!
Thanks a lot...i have been in IT field for a long time...many times i tried to understand keys, certificates etc... finally this video gave me a clear understanding ..thanks again.
Mr Crabbe. OMG. I am working on my degree in Cyber Security. I am currently taking my Cryptography class. Unfortunately the study material is absolute garbage. I have had to resort to outside teaching material to learn. Thank you for this video. It has helped me a ton.
grin.. glad it helped
This is simply brilliant..and brilliantly simple..great job!!
UHTi iklkouuo
Explanation is complete with the real time example.
Though i know these things, i still liked the way you explained.
Thanks a lot.
Wow! Really great explanation. Really clears up a lot of questions I had about CA, Digital certs and how TLS uses asymmetric/symmetric encryption and why symmetric is better. All of of this knowledge in one place! Thank you.
Thanks for the tutorial, it's much faster than any other method I came across.
The best explanation I have heard. Very calm and clear. I got everything and I an not language native.
thanks for the kind feedback. Glad it helped with this topic.
The best explanation I have encountered. Made it very simple and clear. Thank you !
I have been working on my understanding of certificates and PKI. This clarified a few additional things for me. Thank you for the info and details!
One of the best explainer videos. Very easy to understand and covers all the basics
Very good tutorial , covering symmetric , asymmetric keys , SSL , how certificate is generated and signed......
Amazing, best digital certificate explanation on youtube!.
one of the best explanation i saw on the subject, specialy on the self certificat CA
thank you
Dave, Thank you very much for such a clear and complete explanation.
Thank you. have seen many tutorials but this is the first one that makes complete sense to me ! Best wishes...
Taking Security+ in 2 weeks. Every bit of extra info helps. Thank for clearly explaining ssl communication.
Excellent explanation of a complex topic. Beginning the video with a review of symmetric and asymmetric encryption was super helpful and really paid off at the end. Thank you for producing and sharing this video!
Thanks for the comment
Perfect demonstration, it include awesome theory and practical .
I am fan of you video now !
Amazing video on digital Certs, if you land here just think you got your answers with this video
This world needs more people like you
This is just awesome... The first diagram was worth millions
Ive been in this industry for years, I tell you this is the most comcise, informative and to the point video about cert. Thank you
One of the best explanations on this topic. Thanks Dave 👌
This is very helpful for the reader simply explained and with good examples. Really amazing video.
Thank you for sharing. This is great - explained in its most simplest form.
Dave! Great video! I'm very impressed how simple is that! Thank you!
This was really informative video . Thanks Dave ! Hope you keep creating these type of instruction content !!
I hope you’re still around. That was explained very well
grin.. yes.. but retired from the College.. I still do the odd videos, though..
Awesome video
Complex concepts explained in simple way
Appreciate your efforts
Amazing video. Thanks Dave for making it so nice and clear.
Thanks for the great explanation. This helped a lot to understand the topic!
Lovely lecture! You took enough time to explain the concepts at ease.. Thanks.
Great tutorial. It took me a while to shake off the confusion caused by hearing "ncss.ca" and assuming the .ca meant it was a CA.
CA=Canada
You are right. It took me a while too.
Better to use .com for example. (ca seemed to be CA at first.)
yes.. If I redo.. I will not use .CA.. am so used to that domain; being from Canada...
@@davecrabbe4579 ... no issue for us Canadians :)
Wow! I am really impressed. Thank you sir! Much love from germany
this video gives lot of information in very simple terms. thank you
Very well explained Dave ! Helped clear understanding of flow between browser and webserver. Keep uploading the such great videos. Many Thanks
Excellent explanation.. Best on Internet
Thanks Dave, you're a great teacher.
I had a doubt between public & private key but, after going through your video session I got the difference between them.
The best tutorial in the net about certificate
Perfectly explained. Great Job. It helped me a lot. Thanks, Mr.Dave
Nice explanation!
OMG, you answered all the questions I didn't know I had. Thank you!
Thanks for this video, best explanation on the net.
i'm now your subscriber ! Great job Dave !!
Thanks a lot Dave the video was a bit slow but now I understand completely the key exchange!!!!
Watch at 2x speed, very great breakdown!
thanks a lot for a informative video. Very well explained!
Very good explanation, thanks for the effort!
Good one. This tutorial has cleared my basic concepts about ssl
best tutorial. thanks a lot Dave !!
Thank you for this amazing clear explanation
Great! Finally I got the whole process. Thanks a lot!
I literally fell asleep listening this gentleman
Is that a good thing?
SO SO SO easy to understand, thank you !
Thanks a lot sir...very detailed lecture finally i understood this topic
Dave - Thank you so much for sharing this. It is a great review even if you deal with it a lot. Good work
this gives a very good understanding about the subject... kudos
Great tutorial Dave! you made it simpler to understand
Excellently explained
Knowing something about the topic, I can understand what the poster is saying. I wonder if I had understood that without knowing anything. As a side note, the blue arrow 3. should not exist; nothing is conveyed from the server to the browser at that point.
Awesome explanation
Many Thanks !!! for your kind and detail Explanation.. God Bless You !!!
best explanation ever! Thank you!
Great explanation! Thank you.
19:36 wait so the security certificate and public key are sent from server to browser, and the browser uses an internal list of certifying authority to validate authority of the certificate? It doesn't make any calls to the certifying authority server (like in DNS)? Maybe I'm missing something but couldn't the server spoof a certificate to only look valid?
No.. your browser has access to the public certificate of the company in question (we'll call it ACME). So no server can spoof a certificate from ACME because a certificate from ACME is encrypted with ACME's private key. Only ACME has their own private key. Everyone has ACME's public key which is used to decrypt the certificate.
I was wondering how a 2-way communication is being established; since before you discussed symmetric session key, it seemed like only the server can receive encrypted data while the browser is simply the sender, not the receiver. Now I see. Thanks.
Hi Dave, nice video! One thing which is not fully clear to me: since CA signed certificates are public what does prevent a man in the middle from using the public certificate of for example google and pretending to be google?
The CA signs their certificate with their PRIVATE key, not public. Everyone has the CA's public key so everyone can decode the cert. and know it comes from the actual CA. Since no one has the CA's private key, no one can 'pretend' to be the CA. When a CA issues an SSL cert, it signs the cert with the CA PRIVATE key, which only they have. An imposter should never get any CA's private key and so can't issue a fake SSL cert. (in theory)
@@davecrabbe4579 your point is clear. My question was more on the fact that certificates seem to not guarantee that you're talking with a trusted party but only that the public key inside the certificate is the actual public key of the organization reported as being certified inside the certificate (So an imposter could not issue a fake SSL cert but he could still re use a valid SSL certificate pretending to be the organization being certified). If this was the case, certificates would be only effective in conjunction with TLS (in this case the imposter could not decrypt the messages inside the TLS session not having the private key). Correct?
Certificates actually contain much more information than I have listed here. And this is done to keep the concept simple. Actual SSL certificates contain the URL that they are assigned to. So if Evil.com steals NSCC.com's SSL cert, it can't put it on evil.com because the browser will block it. But I think your point is valid. If Dr Evil steals NSCC's cert, there is no point in sending it to someone as Dr Evil can't encrypt anything with NSCC's private key as they don't have it. But there are many, many more details on SSL than I have presented here.
@@davecrabbe4579 Great work you are doing to society !!!!
[doubt] : server sends CA cert to client which contains server's public key. Now most browser's or hacker can have CA's public key which it can use to decrypt certificate and get server public key. Now in further communication he can act as client(identity theft) and send his own symmetric key encoded by server public which he stole.
How is this prevented or am I missing something
@@shahzadhassan2518 yes.. you are missing something. All public keys are public. Anyone can get anyone else's public key. You don't decrypt with a public key, you only decrypt with a private key (in this scenario). A client takes the server's public key and encrypts a session key and sends back to the server. A hacker can send a different key back to the server, but the original client would not use that key and so no client private info is compromised. Anyone could potentially send a symmetric key (encrypted with a server's public key) back to the server, but then only info can be exchanged between those 2 parties. Other client's private info never enters into that session.
Thanks for the video! This finally made it click for me.
wonderful explanation !!!
Hi sir !!
If we make the request to any webserver and it share digital certificate along with its asymmetric public key. Then we can share data through assymetric session.. Then again why we are doing the symmetric session and sharing data through symmetric session??? Anyone pls let me know ...
Thanks !!!
Asymmetric encryption is very slow.. it is just used to exchange the symmetric key.. Once both ends have the symmetric key, they then start their session with that; since it allows much faster communication.
@@davecrabbe4579 Thanks a lot sir for clearing my doubt !!
How is the client/browser authenticated by the server? It seems that an imposter can pretend to be the client just not the server since server uses public key and client does not use public key. So, is client using a self-signed certificate (created by its private key, which can be decrypted by its (client's) public key) ? Also isn't Diffie-Hellman exchange the standard to produce a shared secret for symmetric encryption?
A self-signed cert is NEVER used for clients connecting to an unknown server. They are only used for internal testing and within an organization. They do not provide any guarantee that the certificate holder is who they say they are. Enter the Certificate Authority that validates an organization and creates an SSL certificate FOR THEM, that they can distribute. This SSL cert contains the server company's public key. This cert is encrypted with the CA's private key. The CA public key is in the public domain and any client can decrypt the cert to ensure it is a 'good' cert and the server they are attached to is who they say they are. So now I am attached to a 'good' server. The server uses its private key to encrypt a symmetric key. The client got the server's public key in the SSL cert and can get the symmetric key. Now both ends have a symmetric key to use for further communication. See the video on "Chain of Trust" as well.
Thank you very much for this video!
Thank you I am reviewing the concept you explain it clearly. In your symmetric key exchange part which uses pub key to create session key, is this the diffie Hellman key exchange or is that different. This part I want to clarify.
Diffie Hellman used prime numbers to establish a shared secret between 2 parties. It is a precursor to using RSA(PKI) to exchange a key. This video does not describe the details of any particular system in use today. It is designed to show the common concepts that allow a shared key to be exchanged, using PKI. From this, one may look into the details of a current system and the fundamentals here will help you understand the more complete and complex system currently in use.
Thanks for the amazing Tutorial!
such a wonderful explanation...I really appreciate the effort
@6:10 you say certificates contain a public key. Is it the CA's public key or the website I am visiting public key?
I am just describing some general charactistics of person certificates there. A certificate from ACME corporation contains information about ACME corp plus its public key. Root CA’s certificates are public information and often installed inside many OSes (Windows, macOS) and contain the public key of these root CA’s. This allows anyone to get a root CA’s public key so it can validate a digital signature from that organization.
amazing explanation
Wow great explanation!!
Excellent video
Thank Sir. Great lecture. 🙏
Amazing explanation! Concise and clear
I have a doubt. is pubic key sent separately after cert verification or it uses the public that is in cert just after verifying?
Excellent tutorial. Thank you.
where does the symmetric key is stored on the client and server?
No sure what you are asking.. The symmetric key is actually created by both ends, through information they exchange using the asymmetric protocol. Because only those 2 can exchange info using the asymmetric protocol, no one can intercept the symmetric key they generate. They both generate the same symmetric key and store it locally. Once this is done, all communication then uses the symmetric key encryption because it is faster.
can any one answer, who creates browser public and private keys? i never remember creating one to share public key to server to encrypt the message ?
When you create an account on your desktop computer it creates a private/public key pair for you. On Windows it is kept in the Certificate Store, in MacOS, in the KeyChain. These are tied to your user account. Since phones and iPads are single user devices, I assume it creates one when your device is first set up. It is done in the background and the user is unaware of it. There is also software apps that can create public/private key pairs and allow you to use those pairs with applications such as email. In this way you can exchange encrypted email with others. Since a person is not a well-known public institution, the person must send their public key to others to use. In email, when you sign and email, you are sending your public key to another. They use this key to encrypt a return email. In the return email, the other person can sign their email (which contains their public key). Now both of you have the public key of the other and can use that to encrypt mails to each other. You use your private keys to decrypt.
Can some explain to me how a client browser 'knows' that a certificate really comes from the intended webserver? What stops a hacker getting a signed certificate from a genuine webserver, copying it, then using it for a man-in-the-middle attack?
A few ways.. and I don't know all the protection schemes.. 1) an SSL certificate is only for a specific web site .. and so the browser will look at the web site name inside and compare it against the site the browser is attached to.. 2) the browser uses the web site's public cert to encrypt info back to the web site and only the original web site can decrypt with their private key.. To get around these issues, the man-in-the-middle must modify the SSL cert.. as soon as this happens, the checksum is altered and must also be changed. I believe the checksum is imbedded in the digital signature of the cert. Since the digital signature part is encrypted with the WEB SITE private key.. when the man-in-the-middle changes the checksum, they must also re-encrypt it with another private key.. as they don't have access to the original web site private key.. The browser uses its local certificate store to get public certs of those that sign SSL certs.. and so the browser gets the public cert of the original web site issuer and tries to decrypt the signature/checksum part. It can't and so knows the cert has been compromised and will not connect to that web site.
The best tutorial