Hello and welcome. My name is Tyler McMinn, and this is the Aruba Network Security Basics course, a Hewlett Packard Enterprise company. This is Part 2 in our video series, where we are up to video number 14 talking about public key infrastructure and signing certificates. In the last video, we went over the broad strokes on public-key infrastructure and how you see it in a day-to-day network, like the company you might work for. In this video we're going to tie off this idea of certificates, and talk about signing certificates and the chain of trust. Let's jump on in. All right, so certificate signing; we want to prove who issued this certificate and prevent any tampering of that certificate. How does that work? Well, I already talked about in the last video how if you want to generate a certificate as securely as possible, there are plenty of free applications that you can use to just create certificates. That's trivial for a computer to do that; create a random accompaniment of a public-private key pair that only the private key can decrypt the public, and the public can decrypt the private. You can do that on your phone and your laptop, whatever. In labs, we demonstrate this using OpenSSL. Once we've completed the certificate, we want to get it signed off by some signing CA. Process we examined for assigning any data uses asymmetric encryption. The sender signs a hash with their private key and then anyone who receives that hash, can only decrypt it with the sender's public key. What we want to do is include the public key whenever we send out an email or send out something encrypted that we sign, so that any of the recipients can decrypt it, run their own hash, and validate not only that it came from us because it was decrypted by our public key, but also that the message has not been altered in any way; the integrity is intact. This whole process in public-key infrastructure relies on a root Certificate Authority; a server that signs these public keys for us. The root CA does not need our private key to know that it is us. We simply submit it a public certificate with an X509, what we call certificate signing request. Alice here generates her certificate, issues a certificate signing requests to a trusted root CA. The root CA then questions, is that really Alice? If the root CA is satisfied that it is, then the root CA can take our cert and the CA can sign the cert with its own private key. Again, not sending the root CA's private key, that would be disastrous, but instead simply signing the hash of the cert with its private key and then sending it back. Everybody in the organization who trusts the root CA, because they've installed the Root CAs on certificate and their trusted root certificate folder. Everyone who trust that CA will trust any certificate that's been signed by that CA. Anybody who trusts the state of Washington will trust that the information on this card is valid because it's watermarked and everything else. Even if you have intermediate CAs and issuing certificate authorities handling that functionality, they've been signed off by the Root CA before it was taken offline. Something to note here. Who signed off on the Root CA? Well, it's self side and that's enough for us to go ahead and establish trust in this environment. Just a little note here, it's not perfect. You can hopefully start to look at this and think well, you've got to trust that the private search don't get lost. You have to trust the root CA. What if the root CA gets compromised? Will that mean that this whole thing falls apart? Yes. That's exactly what that would mean. [inaudible] was trying to think like a penetration tester. I like that. So validating certificates with a chain of trust, because the CA is not, we don't always want to leave it on the front lines exposed all of these requests where the CA can sign off on an intermediate server to do its dirty work. You take a server that's going to be your intermediate, generate a public key for the intermediate cert and guess what? You get the root CA to issue a signature off of that intermediate cert saying this intermediate has my seal of approval to handle all of Alice's certain needs. When Alice generates a public key, Alice wants to get that public search signed off as belonging to her. She can go to the intermediate cert and the intermediate cert can issue a signature and say, ''Hey, it came from me''. Because the intermediate search through this chain of trust ultimately ends at the root certificate authority. We trust everything that the intermediate does. So Alice sends a cert to Bob with Alice's cert. Now Bob needs to know is Alice's cert valid. Well, he can look at her cert and see that it was signed by the intermediate- While Alice could also include the root CA certificate, Bob, would be like, "Who's this intermediate signed off on"? Well, the intermediate cert, which you see right here, is signed off by the root cert, and Bob's like, "Who's this Washington's state, who's this root CA you talk about"? Alice will be like, "Oh, don't worry about it, let me tell you everything about this guy". If I lived in the middle of the United States on some piece of territory that I claimed as the land of Tyler and I signed off on all of my own driver's license as Tyler's state. Welcome to my state and I have approved my driving privileges, Bob, who doesn't trust Tyler's eminent domain over signing a certificate, or issuing a driver's license might question this. If I send him a root CA and Bob accepts that root CA and says, "I guess Tyler's is a valid country now", then, great, all of this works. Generally, we don't do that, we don't send the root CA. Bob should already have the root CA that he does trust and not on his brain, but in his computer already installed. In the lab if you go through the full four-day class, we go through that installation process. Best practice, we don't really include the root CA. Alice would send her cert and maybe the intermediate CA along over to Bob. Bob can then follow this chain of trust, look who's signing off on Alice's, look who sign to the intermediate CA look who sign i the intermediate CA and establish that, that public key that the intermediate CA has to validate Alice certificate, which does work. It does decrypt and shows that Alice's cert is valid and a valid match can then go on and look at the intermediate CA and do the same thing. So he first validates Alice's against the intermediate, then he validates the intermediate against, you guessed it, the root CA, and just follows this chain of trust. The public key that signs off on the signature of the intermediate checks out and the root CA then being the trusted issuer, needs no introduction. That would have already been installed ahead of time on Bob's computer. The reason this works when you go to a public website, like a bank website, is that your operating system, your web browsers would have downloaded root certificate authority is what we call third party roots CAs like DigiCert and Verisign, companies like that, whose whole job is to issue these certificates for websites for public companies and they go through a number of steps. DigiCert and Verisign, they take the money of the company to sign their cert and they spend time checking public records and validating the company is owned by XYZ and that they respond to their phone number and that they respond to certified mail. They go through the hoops to validate that this is indeed Capital One or Bank of America or some bank that's trying to get validated, or any company really doesn't have to be a bank. What does it mean for a root CA to be trusted? The root CA needs to be installed on the operating system and this is an example of Windows running at a certain management utility where you can dive in and see all the search that are held by the operating system, your personal certs, and those that are trusted root certificate authorities. These come with the operating system and you can add to these carefully, but you can add to these. If you have a laptop that's being used at your company, these public-issued trusted roots CAs are probably not going to be used. Instead, you'll use one that is the Windows certificate authority or the clear path certificate authority that your company has. That would be installed through Windows group policy or when you update your operating system on your laptop, or when you were handed your laptop. You can do the same thing on your switches, you can do the same thing on your mobility controller. In the lab, we'll do exactly that, we'll install a trusted root certificate authority that we generated just for the lab onto these devices. What else needs to be required for a certificate to be valid? A trusted issuer and remember, it cannot be expired. Also, even if it's not expired and it's issued by a trusted issuer, we can check and see against a certificate revocation list if this has been exposed or the private key has been compromised. We can revoke it and then when someone goes to check the public cert signature, it'll fail because it's on a revocation list, and also that it's using the right valid usage and it matches the issuer in the identification field. A quick example of what this looks like, you go to a web server and the web server might throw back an error message here saying valid signature, valid period, and all other criteria, but no subject alternative name has been issued. In other words, the IP address or the name that's being used here, it doesn't match the device that you're actually going to, so cert common name invalid. It may indicate that you're being redirected to a website or an IP address that the cert is not associated with, even though the cert is valid in all other cases. So quick pop question, match the entity on the left to the description on the right. Just like the last video, I'll go ahead and show you the answer when we come back. I'll see you guys in the next one where we are going to start looking at applying this to real gear in real circumstances that you guys would use throughout your normal workday or even at your homes in some cases. Normally working environments though, most houses don't use public-private key pairs to tell whether your husband or wife or brother or sister or whatever is logging in into the wireless network just using a pre-shared key. I'm going to show you deploying this in the wireless world and what that looks like. Thank you very much, I'll see you in the next one.
