Digital Certificates: Chain of Trust

[@davecrabbe4579]

At 14:27, you will see that the CNNIC cert is indeed listed in the keychain of the macOS (an oversight by me). However, built into browsers is a "black list" where the browser itself can invalidate a root certificate. So when Google found the breach, it added code to the next update of its browser that will effectively revoke CNNIC's root cert even though one appears in the operating system's certificate storage area. When users launched Chrome, it will search for an update.. when one exists it installs the new code and .. there.. that certificate is revoked and so Chrome will no longer validate CNNIC's certs. I believe that browsers have both white and black lists of root certs built into their code so they can add root certs, if they don't think one exists in the OS, or invalidate root certs. But all OSes have a central storage area for CA root certs so browsers don't need to store a complete list.

[@DataVids]

Can we see the blacklist that a browser, has for root certs? Or do you think that is intentionally hidden from end users?

[@davecrabbe4579]

@@DataVids I am not that familiar with the internal workings of all browsers. Chrome contains a CRLset that is a list of banned sites. It can’t be viewed directly but can be dumped with public code. (dev.chromium.org/Home/chromium-security/crlsets).

[@DataVids]

@@davecrabbe4579 thank you!

[@pabloignaciodambrosio8850]

Ha, I was about to comment that!. BTW in my key chain it is not. So at some point Apple also removed it.

[@jimgloriavaughn8683]

This has to be the clearest, melodrama-free explanation of digital certificates on KZbin. Thank you for taking the time to explain this.

[@Ilitan004]

I finished my IT studies 2 years ago and never got clear in certificates understanding. Now I wanted to acquire this competence once for all. Watched many videos, still didn't get the thing. Then I found yours. This is masterpiece explanations, everything is now crystal clear into my mind. Most of the videos skip steps so it's not understandable. Thank you so much for this high quality lesson.

[@subrahmanyammamidi5298]

This is by far the best explanation on Certificates.

[@shamilsaleem9444]

Indeed!

[@sonicbytess]

clear explanation without using any fluff or word salad, straight to the point! thank you!!!!

[@messiweltmeista]

Amazing explanation. What I couldn't understand for over 2 months was water clear in less than 30 minutes. Thanks.

[@ashayfernandes4722]

Searched the Google, searched KZbin didn't find a good explanation of certificate for beginners, THIS VIDEO IS GEM IT HAS ALL THAT A BEGINNER NEED TO UNDERSTAND. THANK YOU FOR THE VIDEO!!!

[@ValliNayagamChokkalingam]

Excellent explanation! Searched everywhere to lean more about how the chain of trust worked in detail - finally found it here! Thank you!

[@davecrabbe4579]

Thanks.. older video, but its all built on the same basic concept, so far.

[@MrEdgaravi]

Thank you Dave, excellent explanation!! Clear and direct. Agreed that this is the best chain certificate explanation I´ve ever seen to date.

[@Zeid_Al-Seryani]

This is the most amazing video I have ever passed by , because you are the only one I saw that explains the SSL and Chain of Trust in details with a great example. Thank you very much dear and I am very happy that I have passed by while I was searching on tutorials to understand how this process works. Best Wishes and Blesses.

[@davecrabbe4579]

Thanks..

[@anilkommalapati6248]

Awesome tutorial. I am struggling to understan the chan of trust since ages and today this tutorial has cleared all my doubts. It made my day. Million of thanks to Dave. Long live and god bless you.

[@dennisyi5658]

thanks for taking the time to post these videos. i'm a network engineer and your teaching and explanations are excellent! appreciate it!

[@davecrabbe4579]

Glad you enjoyed it.. thanks

[@jpranav4u]

This is the perfect video i found in youtube which explains the concept of cerficate chain.. take a bow Dave

[@odesferreira]

A great presentation about chain of trust and certificates! Really great. Thanks for that

[@AnhNguyen-vu7mc]

This is the best explanation so far on the internet

[@jmrah]

Straight forward and comprehensive explanation. This is the only resource on the topic that made sense to me and filled in all the gaps.

[@MrHarvindermann]

This is the best video on SSL I have come across!

[@sharpie04]

I'd like to echo what others have already said and thank you so much for such a clear explanation of this process. I have been able to explain PKI principles to colleagues from the knowledge learnt in this video. I've been an IT professional for the past 9 years and PKI principles have never really stuck but this one made the penny drop. Excellent work.

[@thabangmasigo1288]

This is great and simple, finally someone covers how the certificate is verified to actually be from the specific CA.

[@magawla]

The best explanation ever I've faced about "Chain of Trust". By the way, you have the root certificate of CNNIC on your browser. :)

[@davecrabbe4579]

yeah.. I picked that up after it was posted.. I'm still learning too :)

[@surendrababu1150]

I had so many doubts / confusion about digital signature and how it works, now i understood completely, thanks for the nice explanation

[@pja8901]

Finally! found some quality material... and it was free. thanks

[@usernamewatcher]

the best explanation on youtube I've found so far thank you so much for your work!

[@philipperivest7806]

Sir, the video is simply perfect. I work in IT, I dont play a lot with certs or CA but this was to the point where i had enough to do my job. Thanks :)

[@pallenrupp]

Thanks Dave! These two episodes on TLS certificates was the best I have seen. Thank you, Thank You.

[@johncruz3135]

A fantastic and clear explanation of the Chain of trust..Kudos!

[@karamjeetpadam4719]

this is the best and most simplified explainnation of topic... loveed thatt...thanks much for your efforts

[@vasumahalingam5162]

By far the best video on this subject. Thank you.

[@varelarick]

Wow, you made understand those SSL certs once and for all, and it's much appreciated. Also, you have a great hand writing. Keep up the great content sharing in your channel, I'm definitely subscribing.

[@BiswaRSingh]

This is really awesome explanation. Probably the best that i have ever seen till now.

[@AnasAther]

This is by far the best explanation, if you have basic understanding, I learned first 3 chapters from book called PKI uncovered from cisco press and then watched this video, which resolved all the grey areas, thanks man

[@davecrabbe4579]

super! Thanks for the comment.

[@yogi029]

One of the best and crystal clear explanation I have ever seen !!

[@VikasAgarwal84]

This is the best explanation across all articles and videos.

[@cliffBMRC]

Excellent instructional "Chain of Trust" SSL process. Thank you for your valuable time. :)

[@Piquetures]

I've been watching SSL related videos for the past hour and this explanation at 11:52 was what I needed to fill the gap!

[@tnb178]

This is not how it works nowadays. If you want information about that part, look for diffie hellmann key exchange.

[@crisag.2698]

Yeah the latest version of SSL was deprecated in 2015

[@tnb178]

The problem is if the private key ever gets compromised at some point in the entire future of humanity, all past communication becomes compromised. Not good. Private key should only be used for identification and after a breach simply be replaced without further damage.

[@nimble_skr]

One of the best videos to understand chain of trust

[@martinwangwe8966]

Thank you Dave for the excellent presentation and i like the case study you put at the end.

[@MrMarkyr1000]

At 14:25, you can see CNNIC ROOT listed in browser certificate list.

[@MukulTripathi]

I had to change the speed to 1.25 and the video became so much better! Thank you for the nice explanation.

[@davecrabbe4579]

grin.. I'm older and I go slow these days..

[@pontustervehn1264]

This was a nice and comprehensive step-by-step overview! I've browsed through a bunch of information regarding certificates, validation etc, and this video turned out to be a gold nugget in a topic where other information sources choose to gloss over the details and specifics (perhaps due to a lack of understanding?).

[@davecrabbe4579]

Some go into too much detail and you never grasp the overall concepts.

[@mohamedshageaa]

Thank you! This is the best explanatory video for ssl certificates

[@magawla]

Best explanation about chain of trust I've ever faced.

[@shivamverma9447]

best explanation!! well done

[@NBAUSACRIC]

Seriously love the way, the information provided, clear concept

[@enigma_mysterium]

It's was an deep and easy to follow dive into the e-certificates world. Many thanks!

[@jmrah]

Finally an explanation that connects all the dots! Great explanation.

[@joja9413]

This is THE BEST explanation ever

[@SeeuD1]

At 10:30 you show that Google signs with the Private Key from Geotrust, and Geotrust use the Public Key to encript the Hash. But isnt it vice versa and Google is signing the Hash with the Public Key from the NSCC and they validate it with their Private Key ? Because why should Google have the Private Key from Geotrust ? And at 14:40 the CNNIC is seen in the picture where you say it is not valid to use it ?

[@davecrabbe4579]

No, you are misunderstanding the information here. Here, Google is an ICA and as such, no client has Google's Public key in their certificate store. As an organization, Google must obtain a certificate from a known and trusted CA (GeoTrust). Thus, GeoTrust creates a cert for Google and signs it with their own private key. You are right, NO ONE must see the private key of another. This cert is sent to Google and they distribute this cert whenever Google issues a Cert. In the case shown, Google is issuing an SSL cert and encrypts the hash with their (Google's private key). The client would not have Google's public key and so could not decrypt the hash. This is why the Google cert (signed by GeoTrust) must be sent with the SSL cert. Every client has access to GeoTrust's public key since they are a well known CA. They can validate Google's cert and get Google's public key and they use this key to validate the SSL cert.

[@SeeuD1]

@@davecrabbe4579 Ah now I get it! Thanks! 😊

[@muhannadak8087]

Thanks a lot! great explanation. But I'm a little bit confused, 10:12 where you said the browser has the public key so it can decrypt the data encrypted by the private key. But I thought public key is used to encrypt and not decrypt. Can you please explain?

[@davecrabbe4579]

In PKI, either the public OR the private key encrypts.. the OTHER key will decrypt.. This allows different applications of PKI.. such as digital signatures vs SSL communication. So in SSL, the PRIVATE key of the vendor you are attached to encrypts some information and I (the client) can decrypt it with that vendor's public key. If I want to send something secure back to the vendor, I can encrypt it with the Vendor's public key and they are the only one who can decrypt it with their vendor private key.

[@rakesh4a1]

Need a bit more explanation at 10:26, How hash is validated? Correct me: the decrypted hash from the received 'google-certificate' using public-key of root CA installed in browser is matched with the generated hash from public key present in the certificate?

[@nathanwashor89]

I agree with earlier comments. This is the best video on SSL I could find on KZbin. I shared it with my coworkers. Thank you.

[@davecrabbe4579]

Thanks for the comments. The actually technical implementation has so many more details. I tried to distill it into the core concepts.

[@onlyeyeno]

Many thanks for this clear, concise and well presented explanation, Best regards.

[@lerneninverschiedenenforme7513]

Q@ 10:10: (1) The browser does not need to specifically request each single certificate, but instead gets all certs on the server at once, right? (2) What happens in cases of longer chains? For example: NSCC -> Google CA -> GeoTrust -> CompanyA -> GoDaddy. Would NSCC have to provide each certificate of the chain? How does NSCC know which CA is actually listed in the browser? (3) What drawing/presentation software are you using?

[@davecrabbe4579]

There are not that many intermediate CAs in a chain. Generally there is one intermediate cert and then the root CA. NSCC would send its cert and all other public certs needed to validate its certificate. They are not requested individually. I used a Sketching program from Adobe that I don’t believe they still provide.

[@lerneninverschiedenenforme7513]

@@davecrabbe4579 Thank you :)

[@cw5948]

Thanks for delving into the details of this process. Other videos don't seem to discuss the details in much depth.

[@I9Chris6I]

Finally a satisfying explanation of certificates, thanks

[@atexnik]

BTW, I can see CNNIC ROOT listed in your browser.

[@MajidFouladpour]

14:27

[@SlowCarToChina]

LOL - I was just about to post this exact same observation.

[@keeranmnc1605]

lmao

[@Flankymanga]

hehe small mistake but we got the point....

[@loayzag91]

If Microsoft didn't revoke CNNIC, then it may be reasonable to believe that Apple didn't either. If they didn't, then Safari would still ship with CNNIC as a trusted root and would therefore be installed on his computer.

[@ahmedayman6170]

Great explanation!! Thanks I have question, at 11:14 you mentioned that the public key from the ICA can be used to decrypt the hashed encrypted part from the NSCC certificate. Can a public key be used for decryption? I am still a little confused on this point.

[@davecrabbe4579]

Either key can be used to encrypt. But the *OTHER* key must be used to decrypt. Which key is used to encrypt depends on the application (digital signatures, encryption certs, etc). However, the private key is *ONLY* known to the person issued. It must never be distributed.

[@sutherlandnele]

excellent presentation. one of the best. thanks.

[@HXYZZZ]

great explanation, Thanks Dave for putting this together. really helpful.

[@r-esp282]

I also had trouble spelling Hierarchical! (Thank goodness for auto correct😁) Fantastic explanation btw - I've been scouring the web for a decent explanation and after your video I feel my knowledge gap has been quenched. Liked the video so that after I've had a sleep and forgotten it I can simply refer back to the masterclass. Thanks again

[@mostinho7]

Done thanks took notes in onenote Best video on the topic!

[@ruchit8762]

Hi Dave, thank you for the wonderful explanation but I am a little confused to see the private key encrypted hash is being decrypted by the public key present in the cert when you explain the chain of trust..... I don't get that... cause my understanding is that public key encrypted data is decrypted by private key but here it seems to be vice-versa.. please can you shed some light

[@davecrabbe4579]

There are some applications where the private key encrypts and some applications where the public key encrypts.. If you want to send something private to a friend then you use their public key to encrypt and they can decrypt with their private key.. If I want to “digitally sign” a document, I encrypt with my private key and anyone can get my public key to decrypt.. Since only my public key can decrypt it, it must have come from me. In all cases, the private key is kept secret with the entity that created the private/public key pair.

[@ruchit8762]

@@davecrabbe4579 noted thank you very much

[@davecrabbe4579]

@MetaTreatment I want to send a message to John and have him validate it comes from me. I write the message in plain text. I add my signature and then encrypt just my signature with my private key.. I then encrypt the message using John’s public key.. John gets the message.. only he can decrypt the entire message with his private key.. He then uses my Public key (which I personally send him .. or it could be posted on my personal web site.. ) He uses my public key to decrypt the signature .. since he knows he has my public key.. he can validate that I sent the message. No one but John can decrypt the message. Most email clients support all this.. you can play around with it.

[@osirioncomputing8521]

@@davecrabbe4579 I have never heard of a case where public keys are used to decrypt. This breaks the fundamentals. Rather I can see where encrypting using the public key would match the encryption of a hash. So if you know the checksum of some document you could then use the public key to encrypt that checksum and then check that encrypted checksum against the encrypted checksum sent to you. This solution makes more sense to me.

[@davecrabbe4579]

@@osirioncomputing8521 Used for Digital Signatures. When digitally signing something, you encrypt the signature part with your private key. Since everyone has your public key, they can decrypt the signature.. Since only my private key can be decrypted by my public key, you know that info came from me.

[@artjomzingfeld6881]

Very good tutorial! The only thing I misunderstood is that before you talked that signing is done via public key and then I find out that CA and ICA certificates are signed by CA/ICA private key ?!

[@thetedsingh]

Just wanted to commend you on the quality of your videos in explaining a complicated subject - I was able to clarify multiple concepts after muddling through several documents.

[@davecrabbe4579]

Glad you enjoyed.. With all the complete details, it is a very complex topic. My attempt was to break it down into only the necessary components so that people understand how the basic principle works.

[@fishsauce7497]

Simple and to the point without age old theoretical rhetoric.

[@frankkolmann4801]

Am I missing something? At 14:38 one can clearly see CNNIC root is listed! The presenter says CNNIC IS NOT LISTED.

[@davecrabbe4579]

The pinned post explains that.

[@christorok1906]

This is awesome! You explained it soooo well.

[@__ab4520]

Great video. When you say certificate hash data is encrypted using private key of issuer, does it mean that private is also sent along with certs? I am bit confused, why private key is being used to encrypt hash? Isn't public keys are used to encypt( as browser is doing with symmetric key) ? Or it is not neccesary to encrypt using public key always?

[@osirioncomputing8521]

One piece of information missing in this video that will be helpful: Data encrypted with the public key can only be decrypted with the private key, and data encrypted with the private key can only be decrypted with the public key. So notice that the hash of the SSL certificate is encrypted with the private key and can only be decrypted with the public key.

[@goodev]

Great video. I can see multiple comments of 1) encrypting vs. validation and 2)encrypting with either private or public key and undoing the process with the other key. Second comment that was useful was the reason to using an intermediate certificate authority (a security feature, limit damage if private key ever gets leaked). Thank you! Would it be possible to make a video about wild domain (multiple domain) certificates? My homework now is to encrypt with a private key and decrypt with the public and to compare against other validation/signature verification flows. In JWT, (head.payload.signature) I would thought that you had the payload, you would encrypt it using the public key (generate the signature) and then compare it against the signature for validation.

[@SuperWhatusername]

Thanks Dave for clear cut explanation. Have a good time.

[@michaelndlovu356]

Great and simple.......good job sir

[@gbel7842]

great explanation ... CNNIC was still in your browser though (14:28)

[@davecrabbe4579]

yeah.. see Pinned reply just below

[@stephank.murphy4874]

Great Video, really informative! Exactly the information I knew I didn't know.. Thanks!

[@ruchit8762]

awesome explanation ! cleared my doubt... this clearly explains why do we have chain of trust in the first place...

[@random-characters4162]

great video thanks! What I'd like to see next is what happens if the private key is compromised. My understanding is that the certificates can be forged using this key. But I would like to hear an explanation from a professional! Thank you again for the great content

[@davecrabbe4579]

If the private key is compromised all certificates created with that private key are compromised. If the private key of a ROOT authority is compromised there is a way to invalidate all certificates issued from that ROOT authority. I believe all browsers check some central repository for a list of ROOT authorities that have been compromised and will not process a certificate if the issuer is on that 'black' list.

[@sammyasher]

I thought hashes by definition *can't* be "unencrypted*?

[@davecrabbe4579]

You are right.. I didn't use the correct term there.. Hash is a 1-way encryption.. It is not a hash that is placed in the cert, but cipherText that is encrypted with the private key of the CA(ICA) and which can be decrypted with the public key of the CA or ICA.

[@sammyasher]

gotcha, thanks! Great video/pedagogy.@@davecrabbe4579

[@shaneyh97]

perfect video ,really good explanation to how the chain of trust occurs

[@jonathanfoster2848]

I was interested to see the piece where the browser is able to check the hash, which was encrypted using the private key, by using the public key. So are asymmetrical keys able to be two ways (hashes encrypted using public keys can be read if you have the private key, and hashes encrypted using private keys can be read if you have the public key)? Or am I misunderstanding the whole thing

[@davecrabbe4579]

Yes that is correct. Either key can encrypt but only the other key can decrypt.

[@jonathanfoster2848]

@@davecrabbe4579 Thank you!

[@muditgoel9]

Just one word "Excellent" !!

[@RaffaeleSellittoNiInF]

I have a couple of questions about this: 1) How are root certificates imported automatically in our browsers? 2) There is an automatic check of the entire chain of certificates every time a new certificate is received?

[@davecrabbe4579]

Root certificates are in the OS. Windows stores them in the Certificate Store, in MacOS they are in the KeyChain. Browsers can store them right in their code-base, I believe, as well. You don't need to import them. Yes.. every time you get a certificate the browser authenticates it by validating the certificate chain.

[@tvujtatata]

nice video but how does the NSCC receive its private key when the certificate contains only its public key? nvm after some searching, it generates its own private key and probably share the public key with the CA to receive those certificates.

[@davecrabbe4579]

Yes.. Internally, every company generates its own Private key / Public Key pair using a common crypto application available in all operating systems. It sends only the Public key along with information about itself to a 3rd party so they can validate the company and then they’ll guarantee and issue an SSL/TLS certificate to the company. The company distributes this certificate (which contains their public key) to anyone requesting an HTTPS conversation.

[@mykolamorozov9406]

Around 09:30 - there is confusing naming convention or misunderstanding. There are already 3 intermediate certificates on the picture in the same time: Google CA, Google, Google ICA. Are they all different, or they all are the same?

[@davecrabbe4579]

I missed adding some info here. In the top box where is has "Google CA" it should be "Google ICA". GeoTrust is the root CA. Google ICA is an intermediate CA that issues SSL on behalf of GeoTrust. NSCC does not go to GeoTrust to get an SSL cert, it only needs to go to Google ICA. Google ICA issues the SSL Cert. Since Google ICA is not a root CA, no one has the Google ICA certificate stored in their browsers or Operating System. Therefore Google ICA needs to send its public certificate along with the SSL certificate and both certs are installed in the NSCC web server. When a client connects to NSCC, both the Google ICA and the SSL cert are sent to the client. The client first validates the Google ICA cert because this cert is signed by GeoTrust and all clients have the GeoTrust CA public cert in their OS or browser. Now the ICA is validated, the client uses the public key in the ICA cert to validate the SSL certificate, verifying it comes from NSCC. The client now trusts NSCC public key contained in its SSL cert. So there is one Root CA (GeoTrust) one ICA (Google) and then an SSL Cert for NSCC (this is not consided an intermediate cert.)

[@mykolamorozov9406]

Clear! Appreciate that. Thanks a ton!

[@YSEVERYNAMETAKENGOD]

I was under the impression that public keys are encrypting a communication, which private keys were for decrypting them, but this doesn't seem to be the case. Can you clarify?

[@davecrabbe4579]

Either key can encrypt and only the OTHER key will decrypt. Sometimes we use the Public key to encrypt, sometimes we use the Private key to encrypt, it depends on what we are doing. When we want to have an encrypted session with another site, we don't use this PKI system, we use a symmetric encryption system which requires both ends create a symmetric key. The PKI system allows both ends to create/share this symmetric key.

[@kumarmanish9046]

Can a cert for an intermediate CA be signed by another intermediate CA ? If yes, then how does browser reach the top of the chain till the point where the issuer is a root CA? IN the example browser already has GeoTrust in its TrustStore. What is Google CA was signed by another Google2 CA? Browser won't find Google2 CA in its local Trust Store. Now how browser fetches the cert for Google2 CA?

[@davecrabbe4579]

Yes, an intermediate CA can use another intermediate CA in the cert chain. If the root Google CA uses two interm certs (GIM1, GIM2) then it sends the public keys of those 2 intermediate certs with the certificate and your machine will install them in its certificate store for future use (I think .. either way, it has them for validating the certs). So GIM2 will digitally sign a cert with private key and pass to GIM1 which signs using its private key, and passes to root Google CA to sign. With the cert, the client computer receives public keys for GIM1/2 and the Google root CA is already in its cert store.

[@4epa1012]

14:30 Actually the root CNNIC was listed there

[@kiranpindoria7803]

Great video, Dave. Just one question if I may, when Google sign the NSCC certificate (with their private key) then their private key is out in the wild. How can this be? Many thanks again for the video.

[@davecrabbe4579]

No.. you “sign” a certificate by using your private key to encrypt a part of the certificate that contains your name. Your key never gets contained within the certificate. People viewing the certificate can only decrypt that ‘signature’ (part of the cert) with your public key that is readily available to all. Since only your public key can decrypt that information, people know that only you signed it. The signature also contains a checksum to validate the person signing, but also that the cert has not been altered. Private keys never leave its owner.

[@kiranpindoria7803]

@@davecrabbe4579 Ah, thanks. I think the fact that the public key in the NSCC certificate is to encrypt but the CA public key is to decrypt confused me. Got it. Many thanks again.

[@davecrabbe4579]

@@kiranpindoria7803 You might have missed this fact. EITHER key can encrypt.. you then need the OTHER key to decrypt. So one key is not just for encrypting or decrypting. When you are creating a session key, client takes the PUBLIC key of NSCC to encrypt the session key and NSCC can decrypt with their private key. But when NSCC signs the cert. it uses its PRIVATE key to encrypt and the client uses NSCC's public key to decrypt.

[@alfonsoesteves5090]

I was getting really confused about encrypting things with CA's private key, and the browser decryting it with public key. Then I read that keys are interchangeble, if one encrypts, the other can decrypt, regardless of which one is the private/public. Is this correct? Given a key pair A B. A message encripted with A can only be decryped with B. I believe that is true, but: If a message is able to be decryted with B, does it necessarily mean it was encryped with A. I hope so, otherwise when the browser decryts something signed by a supposed CA, it won't be sure it is a legit CA

[@davecrabbe4579]

Yes.. you are right.. you can encrypt with either A or with B, but you can only decrypt with the other key. So encrypt with A, decrypt with B. Encrypt with B, decrypt with A. There are different applications for both. When in SSL you typically encrypt with a servers PUBLIC key and the server can decrypt it with their PRIVATE key. When you electronically sign a document, you encrypt your signature with your PRIVATE key and the world can decrypt with your published PUBLIC key.

[@alfonsoesteves5090]

@@davecrabbe4579 thanks!

[@rkuvideo]

Great Explanation.. Thank you. God bless you.

[@JosePto]

I got the whole idea and even the trust chain, but I still do not get what is/how a signature works.

[@davecrabbe4579]

Basically a user creates a PKI key pair. A public and private key. The public key can be sent to anyone.. and for large companies, their public keys may be included in an operating system. If I want to "sign" a document, I can encrypt, either a part of the document, or the whole document with my private key and send it to you. I can put my public key on Facebook, if I want. Anyone can get my public key. When you get the document that I sent, you try to decrypt it with my public key.. If you can, then you know I sent it. No one else can encrypt the document in a manner that allows you to use my public key to decrypt.

[@JosePto]

@@davecrabbe4579 so you encrypt the document itself, not a digest of it, or generate a hash and encrypt it (maybe combined with the other two options for integrity check?)

[@lerneninverschiedenenforme7513]

7:03 @Users: Be aware, that the private key is not sent anywhere. A little confusing in the video.

[@davecrabbe4579]

Private keys are ALWAYS kept private. If they ever get ‘out’ then all certificates which are based on it are invalidated and a new Private/Public key pair must be generated.

[@Gukslaven]

Absolutely brilliant explanation, thanks!

[@habtegiorgisdingde4460]

around 11min -- " it uses the public key to decrypt" ?? public keys are for encryption and private keys for decryption.

[@davecrabbe4579]

You can encrypt with one key, but you must decrypt with the OTHER key. So you can encrypt with either the public or private key, but you must decrypt with the OTHER. This is the fundamental principle of Public Key Encryption. When the context is SSL certs, then you are encrypting with a public key. When you are using the context of a digital signature, a person is encrypting with their private key.

[@1001fables]

Dave Crabbe please clear the confusion to me then; here you are saying that a public key can be used to decrypt since it is ssl certificates which we are taking about

[@medgarfsantos]

what he meant is that in this scenario, since you need a way for everyone to be able verify that the certificate is valid, you use the public key (which is public and everyone knows about it) to verify that the certificate you want to validate was generated - or signed - by an entity you trust. and since the private key is known only by its owner, you "decrypt" the certificate (in other words, you "remove" the signature they created with their private key) to see if the file "makes sense" or was not tampered. a simple analogy can be: encryption/decryption: you want only the recipient to see what you sent, so you use the secret key that hides information in a box (the public key). on the other hand, the recipient will use the key (only known by him) to reveal the information. so, the goal is to HIDE the content sign/verify: the sender will sign a document so that everyone can see his signature on the document and the way to do it us signing with the unique key (private). similarly to the legal bureaucracy you need to fill in, for instance for financial or bank purposes. Everyone can read the document and see that you physically signed the document so it can be "valid".

[@aasaithambi2010]

@@davecrabbe4579 Thanks for the info, this hit me another question, if we encrypt using either public key/private key then what is the difference between pub and private key. We can simply have two key named A and B.

[@davecrabbe4579]

No.. you need one key ONLY you know and one key anyone else can know. If you encrypt with your private key, everyone can decrypt with your public key. This is not what you want if you want to send a private message, but it IS what you want when you digitally sign something. This way everyone can verify you have signed it. For private messages, a public person encrypts with your public key and you are the only one who can decrypt with your private key. Absolutely NO ONE should ever see your private key.

[@prafullpandit531]

Fantastic explanation !!!

[@desarrollofacultaddeingeni7137]

Thanks for teaching, it's very clear and understandable. I have a personal question: what software tool do you use for draw and write your videos? I really appreciate your answer

[@davecrabbe4579]

I use an Apple iMac as the desktop. I use the camera built in and simply use the Apple cheap headphones with mic for sound. I use Autodesk Sketch as the page on which I scribble. The layers allow me to expose ‘pages’ as required. I’ve also used a s/w package called ‘DeskScribble”. To create the actual video, I use ScreenFlow. It’s all very lo-tech and relatively inexpensive (except for the Mac).

[@desarrollofacultaddeingeni7137]

@@davecrabbe4579 thank you

[@Chroperafox]

How is the deletion of a certificate (revocation) carried out in a chain of trust if not all subscribers who use the certificate have access to a CRL or connection? Are there alternative ways or how is this solved?

[@davecrabbe4579]

I haven't worked much with revocation lists.. but from my understanding, *every* browser will go to the CA to get a CRList and it will check that the certificate it receives from the server it is intending to connect to.. has not been revoked. So let's say I am attempting to connect (HTTPS) to microsoft.com. When I do, I get a chain of trust that shows microsoft.com was validated by, say, GeoTrust. Before validating the microsoft cert, I go to GeoTrust and download their CRList and ensure that GeoTrust has not revoked the cert. If they have, I give a message to the user saying this is an "untrusted connection" .

[@Chroperafox]

@@davecrabbe4579 Thanks for your answer. In our system is no browser only multiple servers with one main server that has the root certificat and the other servers have certificates signed with the root certificat. When now a server is compromised whe want to revoke it than other server dont see the certificat of this servers as valid. Someone some ideas?

[@davecrabbe4579]

@@Chroperafox Systems need a "protocol" or set of rules for how they make a secure connection. In that protocol, there needs to be a system that checks for certificate revocation. I don't know what system you are using to make a secure connection. You should discuss this with your IT/System admin.

[@EvilSapphireR]

Browsers do the key exchange process in the way you described at 12:00 only in case of TLS_RSA cipher suite. If there server and the browser agree on a better cipher suite like TLS_DH_RSA (Diffie Hellman key ex) or TLS_ECDHE_RSA (Elliptic Curve Diffie Hellman key ex) the key exchange process would be very different. Very good explanation nonetheless!

[@davecrabbe4579]

grin.. you know too much.. I purposely did not want to get into that level of detail as many readers who are just learning this for the first time might not get a good overview of the concept.

[@yadusolparterre]

Why did you choose NSCC.CA ? Is it the same CA? Or is it just the extension for Canada? It's confusing.

[@davecrabbe4579]

I worked for a Community College that had the domain NSCC.CA.. Nova Scotia Canada.. So lectures were originally to my students who had emails of that domain.

[@thegoodanfamily9817]

What about godaddy? For some reason it's on my phone with no CA or root.

[@davecrabbe4579]

When you get a TLS (SSL) certificate, the ROOT public certificate MUST be available to the browser used. On Firefox, all Root CAs are listed in the Firefox code itself. On Safari, it tends to look for the root certificate in the Apple Keychain (which is a part of macOS and I presume iOS). Chrome and Edge, use Microsoft's "Certificate Store". So the GoDaddy root CA has to be somewhere on your phone. Either listed in the browser's software (which you can't see) or in a listing somewhere in the operating system. When a root CA cannot be found by the browser, you'll get a warning message. There is usually a way were you can say "I want to trust this certificate, even though it may be bad" and what will happen is that your device will mark any certificate from that Root CA as trusted. But if you browse to GoDaddy and it connects fine, somewhere on your phone is a copy of the public Root Certificate for GoDaddy. For instance, I just went to GoDaddy.com on my macOS and it connected fine. So I went to my macOS keychain app and I see a listing for "Go Daddy Class 2 Root Cert Authority-G2" expires 2037. If you had an iPhone, it would be somewhere on the phone, but likely there is no way to view the keychain certificate list there. Mobile devices don't give you to tools to look into them and see the details of how they work. They are designed more for the everyday person and try to "just work" without allowing you to twiddle with the inner workings.

[@thegoodanfamily9817]

@@davecrabbe4579 thank you!!! I am positive someone installed an Easter egg on my android, it's a galaxy 9+. They can take complete control of my phone remotely and I'm trying to figure out where I can find a way to track the person who hacked me? Could you maybe point me in a direction most hackers would take to gain remote access to my cell phone?

[@davecrabbe4579]

@@thegoodanfamily9817 Unfortunately, I am an iPhone guy and know almost nothing about the details of the Android platform

[@thegoodanfamily9817]

@@davecrabbe4579 thank you! It's ok. I'm going to take my phone to a local tech guy, or I'll study some of my books for more information. I appreciate your time 😀

[@abhijitv]

AWESOME explanation!

[@rakesh4a1]

Is hash generated from [ + + < info_google>] OR [ + + < info_google> + ] Anyone, please clarify?