Glad you liked it, Jesus. Thanks for the feedback.

Hi, Mike. Sorry for the slow response. There are a variety of good PKI consulting organizations out there. You might talk with Encryption Consulting (www.encryptionconsulting.com) or Komar Consulting (www.komarconsulting.com). Brian Komar also has written several papers and books. I hope that helps.

@@PaulTurnerChannel Never mind. I am glad, that you took your time to respond. Would you mind, if I message you on youtube? I need a couple of tipps for my current project if you do not mind

No problem, Mike. My primary expertise is in the cert and key mgmt of PKI. There many others better than me at CA deployment and mgmt.

@@PaulTurnerChannel can I have your E-Mail Address? I cannot find any way to communicate with you. I posted my E-Mail here in a comment but it got deleted somehow

@@Mike-kq5yc Sorry for the slow response. Please connect with me on Linkedin at www.linkedin.com/in/equio/.

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?

@@PaulTurnerChannel i am using ip address for URL ..yeahh it's private The provided openssl link is not opening.

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.

Thank you, RG!

I’m glad it was helpful, BitVibe!

Sorry, Swagata. That was one of my early videos when I didn’t have a good microphone.

Hi, Les. I’ve been remiss in getting that done. Your message is helpful on telling that the second video would be helpful and serves as a good reminder to me to get it done. I will get to work on it and try to get it done by early February. Thank you for your kind nudge.

Hi, Nader. You are actually correct but with a slight difference. The certificate is passed in the clear. I’m order to prove it is coming from them, when issuing the certificate, the root CA hashes the clear text certificate and then encrypts that hash with its private key. Once it receives the cert, the browser 1) decrypts the signature with the root CA’s public key to get the hash, 2) hashes the clear text certificate, and 3) compares the two hashes. If they match, it knows that the signature is valid. And, since they trust the root CA cert (public key), they trust the certificate. FWIW, the certificate is now encrypted in TLS 1.3 while in transit to the browser from the server. It is encrypted within the encrypted TLS stream facilitated by Diffie-Hellman key agreement. This was added by the IETF (standards group) for additional privacy. They did not want ISPs or others listening on the internet to know the domain name (the subject DN in the cert) that the browser/user is visiting. This works along with DNS over HTTPS (DoH) to prevent detection. The intermediary can a obviously see the destination IP address of the packets but that IP address could be the destination for many domain names. A VPN connection is obviously an alternative but that is not always convenient and the user may not want the VPN provider to have a clear picture of all their communications (since TLS is still used within the VPN connection). I hope this is helpful.

Sorry, Generic Rocker. This was one of my early videos before I understood the importance of a good microphone. Hopefully, some of my later videos have better sound quality. Thanks for pointing it out. All the best.

Hi, Vishnu. I may need you to clarify your question but I’ll try to provide an answer. An MITM can only succeed if the relying party (typically the party who initiated the connection) trusts the issuer of the certificate that the MITM presents. This means that the MITM can’t use a self-signed cert. Instead, they have to convince a CA trusted by the relying party to issue them a certificate with the identity of the subject of the cert (the party that the relying party is communicating with). This should be very difficult if the CA does sufficient due diligence. There have been cases where an MITM compromised the DNS account of the subject and was then able to get Let’s Encrypt to issue them a cert (since LE will issue a cert based on a DNS verification). I hope this helps. Please tell me if it doesn’t answer your question.

@@PaulTurnerChannel thanks Paul, this helps. I was able to listen to some of your videos which explains certificate issuance process as well

I’m glad the analogy was helpful, K-San. I wish I could take credit for it but heard it somewhere else (can’t remember where) and found it very helpful as well. All the best.

Glad you liked it, Niranjan. Thanks for the feedback!

Glad you liked it, Athikora. Thank you.

Thanks for taking the time to provide your thoughts, Diwakar.

Sorry, Anil. That is one of my first videos, when I was still learning the importance of a good mic. I hope the other videos are easier to hear (and understandable.

@@PaulTurnerChannel I just now happened to be at my desktop which has external speakers - now you can be heard clearly at max volume. Perhaps headphones work too. You may want to put it in the description.

Thanks, Sparsh. I’m glad you liked it.

I’m really glad it was helpful for you, Chris. Thanks a bunch for your feedback!

Sorry that this video caused confusion, Profiler. Thanks for the feedback.

@@PaulTurnerChannel thank you anyway Paul!

Hi, k. SHA256 is a hashing algorithm. An HMAC uses an algorithm, like SHA256, in a particular way. Instead of just taking a message and hashing it with SHA256 to get a hash (fingerprint) of the message, you hash the message with a secret key (twice, as shown in the video) to create an HMAC that serves as an authenticated fingerprint or signature of the message. A recipient who has the secret key can verify that the message came from the sender and that it wasn’t changed. On the other hand, if I was to simply hash this message with SHA256, you couldn’t verify that it came from me when you received it because anyone could create a message, hash it, and send it to you. However, if only you and I know the secret key, you know that the message you receive )with an HMAC attached) came from me because you can verify that it was hashed with the secret key. I hope that helps, and sorry it wasn’t clear in the video.

@@PaulTurnerChannel Thank you for quick reply.This is perfect explanation.That means SHA doesn’t provide authenticity right?

I’m glad you liked it, LOL (love the screen name). Thanks for taking the time to comment.