Hello and welcome. My name is Tyler McMinn with Aruba, a Hewlett Packard Enterprise Company. And this is the Aruba Network Security Basics course. Part two, and we are in the 13th video in our series talking about certificates, we've made it to certificates. In the previous video, I left you with a question written here on the board of asymmetric encryption for data signing. If you guess the answer was Alice's public key, hopefully didn't guess you knew it. If you did guess, still got the right answer. I'll give you credit for that, but yeah, Alice would need her public key. So this idea of asymmetric keys and using symmetric keys and signing is tied to identity when it comes to asymmetric keys, what we're going to be looking at is certificates that are going to carry these keys. When Alice sends her public keys she doesn't just send a bunch of 4096 ones and zeros. What she's going to do is issue that key with the 4096 ones and zeros along with who it came from and who signed off that this actually belongs to Alice and what that is called is a certificate. Specifically, you'll often find these in the x.509 certificate format. It used to be something called a PGP key or PGP certificates, where people could just sign each other's keys and lend weight to the strength of them based on the number of people that agreed it was true. But just because everyone in the room is wrong doesn't mean they're right, I guess so. The strength of x.509 and this certificate format is generally what we go with these days and most enterprise environments. x.509 is just the format, it's what form, what key value pairs are we using here. So binding between an identity and a public key, you have the industry standard used for format of digital certificates, we know what we're looking for and what constitutes a certificate. We give it a serial number, who issued the certificate, how long it's assert valid after a certain time, We don't want to trust that certain anymore. We want to issue a new one, who is the subject of the cert, whose cert does this belong to and the key that was assigned to that person and then the signature of it, usually the issuer. This is similar to that driver's license example I gave in the last video or a passport there and the subject in this case, Alice would identify the entity that owns the public private key pair. One thing to make perfectly clear here is we are not sending the private key. At no point is the private key going to be exchanged here in this particular certificate. Now there are instances when you're trying to configure a device remotely or you're configuring 1000 switches or something like that. As an IT person that's doing this, you might derive keys off of the device that you're running it on. But as a best practice for best security if possible, we recommend that Alice create her own private and public key pair and then only the public key ever leave her device to get signed off on and to get approved or whatever else. So even though the certificate authority might issue the signature, it's rare that you would have the CA actually issue the certificates because that would mean the certificate authority would have to hand you the private key along with the public key. And then could you trust that that private key remained private when it was held and generated by the CA, when it was in transmit or transmitted. There's a lot of ifs there, so we'd like to keep it in house on our switches, on our controllers, on our mobile devices, on our laptops. But the public cert we give to everybody, everyone can look at the public cert you can't derive the private cert from the public cert alone. Private cert is its own thing. So the issuer in this case, the certificate authority. This is like the government putting the stamp on your passport or your driver's license, and the certificate authority will be the ultimate authority. That's signing the sign by the power vested in me as your CA server in your environment, I believe this is Alice. What do we use certificates for? Well, like these drivers license, we use them to identify that this person can drive a vehicle in the state with x.509 it's the same thing. We're going to use these for different key usages. You could have a key that's used for anything and in labs, that's often kind of what we do for ease of use. But in more secure environments, it's better to have separate keys for separate functions. This way of one key gets lost or compromised. The attacker who got a hold of that private key doesn't have the key that unlocks all the functions of that user. So you might use one for encryption to secure email, another one for data signing for authentication, another just strictly for certificate signing to authenticate clients. Here's what a certificate looks like, you might have actually seen this. You can open this up and we'll see an example of this in the lab where you pop open assert in your browser or whatever else it will show who it was issued to. This is the client in this case, who it was issued by. This is the certificate authority of trust that we all believe and then the validity date of the cert, best practices to keep your certs about 12 months or less, you can actually see the public key that's included only 2048 bits. Man, can you even trust this? Wait, Tyler, that's not ones and zeros as well as text. Each character is for ones and zeros. What we're going to finish this little video off on is the concept of public key infrastructure. I've been talking around this the last video or two. It starts with agreeing who the root trusted certificate authority is. Usually have a server that's designated as your root certificate authority. In our labs, we have a Windows server that's running as our CA as our certificate authority, you could use clear pass as your root. CA, clear past policy manager It could be a route to, if that makes sense in your environment and then often the root CA. If it's compromised, they get the keys to everybody. So we generally like to install the route CA, issue some subordinates and then we send the root CA off on vacation or we take it offline and put in a safe or whatever. And then all the work is done, the day to day signing and validating certificates and issuing certificates can be done by intermediate or subordinate certificate. Authorities basically certificate authorities that are trusted with the word of the CA and then issuing CA would be used to assign or to issue public certs on demand to other entities. Other devices, other users, other servers in your environment as they need it. because these servers, if I have Bob or Alice here, that wants to send a message to Bob, Alice may want Bob's public key. Well, she can request that from an issuing CA. If she doesn't have it, she could validate that against issuing certificate authority rather than always having the root CA online. But in small environments yeah, you can certainly just run with the roots to this whole idea of issuing. CA, signing certs, generating certificates, revoking certs if a public or private key gets exposed or lost like in the military, you have these CAC card IDs with a private key on a chip in the card. If that card is lost, that's the only place in the world that private key exists, so signing or validating public key is tied to it no longer works. What you would need to do is generate a new card, generate a new key, attached to the identity of that airman or that soldier and then make sure that that's been signed off by the root CA. The previous card and anything signed with it needs to be revoked because it's no longer trusted. Someone could be impersonating that soldier. That's one example where this is a function of running public key infrastructure. The pro you get identifying information, you get to authenticate users and check integrity and sign emails and encrypt, the con is you got to maintain this PKI. And it can be a full time job in a large organization. So this is it PKI. Good stuff, All right. In the next video, what we're going to do is we're going to go on and look at certificate signing a little more detail and we'll look at the chain of trust. So hopefully you guys are finding this interesting following along. You might want to watch this video a number of times but hopefully you enjoyed it. And I'll see you guys in the next one will continue on
