Paul, you are one of the best teachers I have seen on this subject. You made it look so easy. The three part video is the fastest I have learnt a complicated subject :) , and you have a compassionate voice too ! Kudos and god bless you !
Dude...I have never seen such an incredible description of the process...you are incredible! Why cant more people explain such a complex topic in such an easy to understand way?
A most necessary video--this was exactly the piece of information that I couldn't quite figure out (and seems just like hand-waving in other tutorials). Thank you!
I had to look up the translation of Ehrenmann and am now now sure how to respond but to say that I appreciate your generous intention. I could only strive to reach such a lofty distinction, especially amidst all of the incredible beings I’ve been blessed enough to encounter and be in awe of in my life. You are very kind. Thank you.
Thank you so much Paul for this video series. Its been really wonderful. I need a favor. @ 2:00 - 2:18 minutes of this video, you mention that the client machine uses its own embedded certificate (from the software manufacturer) to validate CA1 certificate and the certificate from abcd.com. The picture shows that this processes is accomplished using the Public Keys. Can you please throw a little more light on that process of using the Public Keys for validation. I have listened to the previous videos about 4 times and I am still not able to grasp this particular concept. Thanks again.
This is a great question. If you can, please read the response I just made to Abhishek on the “Introduction to Cryptographic Key and Certificates” video. With that said, I’ll try to explain in the context of your question. Certificates are digitally signed by certificate authorities (CAs) so they can be authenticated as valid. CAs use their private key to apply the signature by encrypting a hash of the certificate with their private key to create the signature. In order to validate a signature on a certificate you receive, you decrypt the signature with your copy of the CA’s public key (which is stored on your computer, typically in the form of a root CA certificate). Please tell me if this clarifies what you’re asking about. I should really create another video that explains digital signatures, as it is a confusing concept. Thank you very much for the question.
@@PaulTurnerChannel Yes!! :-) Thank you so much. It is a simple concept once you explained it. Another video on Digital Signatures (possibly starting with the concept of Hash) would be a great addition to this series.You have a gift and I hope that the good efforts you do come back to you multiplied...
Thanks a ton paul, But still i dont understand how the encryption between user and the server (abcd.com) can be on both direction, now with public key of abcd.com messages to abcd.com can be encrypted, but how abcd.com will encrypt the message to the user.
Vishnu, this is a great question that I’ve been meaning to address in a different video but haven’t gotten to it. In short, a session symmetric key is used. I will use TLS with the RSA algorithm as the example to answer your question in more detail: 1) the TLS client connects to the TLS server, 2) the server responds with its certificate, 3) the client randomly generates a symmetric key, 4) the client encrypts the symmetric key with the server’s public key (from the cert) and sends that encrypted key to the server, 5) the server decrypts the key with its private key, and 6) the client and server both use the symmetric key as the session key to encrypt and decrypt data they send to each other. The alternative to the RSA algorithm is Diffie-Hellman (DH). I won’t attempt to explain DH in this response but it is also used to create a session key that is used between the client and server. I hope this helps. Your question serves as an incentive for me to get that other video done.
What is the data that the private keys encrypt to generate the signature? The algorithm that will verity its authenticity must know the data to compare, right?
Matheus, this is a good question. Sorry for the being slow to reply. First, it is important to understand that encrypting with public and private keys (asymmetric keys) is very slow. Consequently, you want to only encrypt small pieces of information. In the case of digital signatures, where the private key is used for encryption, even certificates are generally too large (even though they're not huge documents). The solution is to use a hash (e.g., SHA2, or SHA1 or MD5 in the past). The signer starts by creating a hash of what they're going to sign (in this case a certificate). The result is 256 bits (the hash). The signer then encrypts that hash with their private key. Finally, the signer bundles the following together to send to the recipient(s): the certificate (the data that is signed in our example), the encrypted hash (which is the digital signature), an indication of what algorithms were use to create the signature (e.g., RSA and SHA2), and the signer's certificate (which contains the public key of the signer needed to validate the signature, in our example this would be the CA's certificate). The recipient 1) uses the public key in the signers certificate to decrypt the signature and get the signer's hash, 2) creates their own hash of the certificate, and 3) confirms that the signer's hash and the hash they just created in step 2 match. I hope this short explanation helps. Tell me if I need to try to explain it again. Since we're signing a certificate (e.g., the server's certificate) and using another certificate to verify (e.g., the CA's certificate), I hope the explanation isn't confusing.
Can we say the presents of Root CAs (or any CA cert issuing CA ) is just to make the revocation of CA's possible with less effort? Is there anything to prevent or at least/identify an attacker who's issuing bogus certificates when he's unknowingly in charge of any valid ca certificate?
Hi, Maksim. Good question. Bogus certificates will only be trusted by a replying party if they’re issued by a CA that the relying party trusts (i.e., they have a copy of the CA’s cert in their local trust store). CAs exist so that relying parties don’t have to explicitly vet and trust an individual self-signed cert from everyone they’re communicating with. You can imagine the amount of work if you had to perform the same confirmation that a CA does for a website the first time you connected to that website (requiring a domain challenge). CAs enable broad scaling and simplify life for relying parties. Thanks for the question. I hope this helps.
@@PaulTurnerChannel thank you very much for your help making it clear. So in conclusion and to catch up on my second question. If we assume there's a chance that a attacker gets away with stealing a ca certificate from a ca. He could issue bogus certs like e.g. for apple.com easily. I'm bringing this up again because I see a few challanges even if we find out about the compromisation in the rollout of a revocation: 1.) coverage 2.) Reactiontime 3.) access to revocation lists might be blocked - by attacker or there's simply no(offline service or lake of list update implementation thinking of embedded systems here) I see 1&2 because clients need to pull the lists themselves. In terms of point 3 I guess it's quite clear now that without access at all to the revocation list we are hopelessly lost, but is there a Szenario for temporary blockage? Thanks a lot again.
I'm sure i'm not the first one to mention those "challenges" and there are well known, so that's why I'm interested to know if there are countermeasures. Actually they would be a interesting topic for another video;)
Hello, Maksim. One other way to “revoke” trust is for software vendors to remove the root cert for the compromised CA from their software and distribute the updated version. This was done, for example, in response to the DigiNotar breach in 2011. However, as you point out, there can be a delay in discovery and response. The Iranian government was able to use the forged certificates for about three weeks before the compromise was discovered. Even when the rogue certs were discovered, DigiNotar did not communicate clearly about what had happened to their CA. The browser vendors finally took the step to remove DigiNotar from their trust stores when they weren’t able to get clear answers. Thanks for you for follow up.
I want to verify the certificate. Iam using mbedtls . But i am getting error -0x2700 - X509 - Certificate verification failed, e.g. CRL, CA or signature check failed How to solve this or are reason to fail the verification
Hmmm. That’s not a lot to go on, K K. The first thing I would do would be to try to connect to the server with a different client that might give you more information about what is causing the failure. You might try OpenSSL (www.openssl.org/docs/man3.0/man1/openssl-verification-options.html). Is this a public or private server? If public, can you provide a URL?
That is likely your problem. You need to use a DNS address that matches the CN and/or SAN in the certificate of the server. That is what the TLS library is attempting to match.
