If you want to wrap your mind around digital certificates you have got to get really groovy with public
key infrastructure or TKI.
Now if you're watching this series by episode in the previous episode I said that P.K. I was a trust
model and that's absolutely true.
But TKI is much much more than that.
Think about what it stands for public key infrastructure.
TKI is the infrastructure that we use for just about every real world application that uses public keys
which is really digital certificate.
So I wish they didn't call it public key infrastructure.
I wish they called a digital certificate public infrastructure but I'm not in charge of the universe.
So we call it TKI.
So what I want to do first in this episode is review the idea of P.K. as the trust model and we're going
to build from that so what I got here is a bunch of different servers.
These are Web servers that need certificates.
Here's an email that needs certificates here could be a wireless system that uses certificates the wireless
networks use certificates as well so there's all kinds of stuff out there that need certificates and
not only do they need certificates but they need to be able to get a certificate a good trusted certificate
when they want it.
They need to trust other people's certificate so if this guy doesn't pay their bill or if they decide
to become evil we need a mechanism that says oh that certificate is no good anymore.
So P.K. is not just about trust Piquet is about distribution it's about control maintenance relocation.
All of this stuff when it comes to digital certificates.
Right.
So let's start off with this.
So what I have here is a peek at my model so up at the top is a certificate authority no certificate
authority is an organization.
So like Verizon thought OK so go daddy there's a billion of them out there and they will have what we
call a root certificate at the very very top of their structure.
So at the top of this structure is some kind of computer storing in here or is one literally one root
certificate.
It's not even signed because who's going to sign it it's their sign and they're the king Anyway this
particular system right here goes ahead and distributes certificates to intermediate systems.
See you don't want this computer messed with it.
It is public access but we don't want people to get to it because this is like the holy certificate
of Antioch here and if this thing gets messed up or corrupted or anything the entire infrastructure
of piquet messes up at least for Versailles.
So this tends not to be a system that's queried or access very often.
Instead we have all of these intermediate certificate authorities that are being trusted by the route
authority and then these guys in and of themselves will create trusts to all these different guys here.
So if this guy right here wants a certificate and we're going to use a sign we're going to go online
to sign and we can do actually handle all of this online we can hand them our public key and all that
stuff online take care of all that and it gets entered in to a situation where it trusts one of these
get the idea.
So really what happens is you'll have a certificate that isn't necessarily trusted by him but it's trusted
by one of his or media who is then trusted by this and then you create what's known as a Certification
Path.
This path is really important because this is the entire maintenance and control structure for any given
type of piquet.
Now we've got to be careful with P.K. because first of all P.K. is not a standard.
There is no standard at all out there that says this is how you'll do it.
Well we do have is one particular standard PKC which was invented by the RSA Corporation back in the
early 90s and PKC which is not a standard it's just the way RSA does it has become the de facto standard
for a lot of piquet systems out there so pretty much if you want to do picquet in the real world you're
going to have to follow PKC Yes.
Now the other thing I want to add to this is that all API is based on a very very old standard called
X-Com 5 0 9 X-type 5 0 9 is really nothing more than a standard that says if I'm far away and I want
to query a database at another place far away how do I go about it.
How do we distribute how do we store information how do we organize stuff in hierarchies so that we
can access data on a timely basis.
It's not 5 0 9 in and of itself isn't even really used anymore.
But the way we queery and talk and do all this stuff is a cornerstone to X-Com 5 0 9.
Now this all sounds great but what I want to do right now is I want to dive in I've got a little laptop
here just a generic laptop and it's got some certificates on it.
Let's go ahead and take a moment and take a look at some certificates and understand how they tie in
how they work and how they try to pick and see is the best place to find certificates is usually through
a web browser.
Now what's interesting is that there is no complete standard that says where are you going to store
certificates on a computer.
But the Web people because they have so much e-commerce have done a pretty good job of standardizing
where things are stored so you could open up any web browser doesn't matter which web browser use.
In this case I'm using Chrome and you can access your certificates where they go.
There it is.
So in Chrome I went to settings advanced I just hit manage certificates today.
OK so here are certificates and yes you can actually get to this from your control panel in Windows
as well.
All right so anyway what I want to do the certificates that you're looking at here mainly are you see
there it says route certificates and then intermediate certificates.
So what you're looking at here are really copies of the route and intermediate certificates that are
copied to your system.
This is just done for speed.
So any time you go to eBay for example you don't actually have to queery the intermediate certificate
authority that you've already got the certificate sitting right here and you can compare his certificate
to the one that comes down from ebay or whatever and you get instantaneous it's good or it's bad.
So anyway.
So here are route certificates Here's our intermediate certificates and then we have personal certificates.
I'm going to save that for a minute.
Let's go ahead and talk about a few things here.
So first of all you'll see we've got three different choices here.
We can have certificates for client authentication.
So this is basically web.
90 percent of the time we have e-mail.
So we have different certificates that are used for email and then we have advanced purposes advanced
purposes actually kind of interesting.
Let me see if I can find a good example so trusted publishers.
So for example I have a very expensive program called Air magnet installed on here.
And every time I run it it actually has a certificate to make sure it's a legitimate copy and all this
kind of stuff and things like some kind of Avery label maker or something like that.
So that's a skip advance purposes.
And for right now let's just go to all.
So we're seeing everybody.
And let's start with a root certificate so I'm just going to pick one arbitrary root certificate here.
Doesn't really matter which one I pick.
And here's a go daddy certificate and let's take a look at this guy.
So I just double clicked it in Windows and I can actually look at the certificate itself.
So basically this is used for authentication primarily for web more than anything else.
And you can see some valid data.
But this first screen is kind of boring so here's where it's interesting is under the details.
So we're going to have different versions there are different versions of certificates based on how
much information you need how much money you're going to spend it makes them more secure.
Some type of internal serial number this is a root certificate so it doesn't really have a serial number
because it is the root.
Here are the algorithms.
Remember what we're doing with these is that we are encrypting some amount of data and then we are then
hashing it.
So it tells us how it's actually being done that tells us who's issuing it.
Now I want you to look here very carefully you see that oh you see that is all X-Com 5 0 9 nomenclature
and it's just the way we organize all this stuff.
There's a valid date valid to here is that some generic subject in here.
Here's the actual public key itself.
So this is the actual public key because remember that's why certificates exist because they pass around
public keys.
The only other thing is particularly interested in here is a thumb print which is kind of like a manufacturer's
serial number.
It's a unique identifier for this particular certificate.
And it can be used for a lot of really important stuff.
Now last thing I want to show you is the Certification Path.
You'll see that this guy is at the absolute top of the Certification Path.
Well he better be because he's a root certificate.
So we don't see any other certificates here but that's about to change.
All right.
So I want to do this again except this time I want to go to an intermediate certificate.
So let's take a look at some intermediate certificate and see if there's a Go Daddy in here.
There is.
OK.
So what I want to do now is go to this guy and let's double click on it.
Now at first glance it's going to look pretty similar but I want to show you there's going to be some
very big differences here.
Notice that the serial number at least has some values in it.
Now but it still has a public key all that same stuff that we saw before.
There's a C R L C R L distribution points we're going to talk about that a little bit later in this
episode.
And so that's the basic guide now in this case.
You'll notice because he's an intermediate authority he actually points to the route authority right
there so the certification path in this particular case you have an intermediate and says that is where
the route comes from.
That was fun.
Let's do it one more time.
At this time what I want to do is I actually have some personal certificates in here.
The reason I have personal certificates is for email I use them for I have a web server built in here
and a lot of other stuff like that so when I want to do is break this down a little bit further and
show you one of my certificates.
OK so first of all you know it says you have a private key that corresponds to the certificate.
Well that's very true because well it's my certificate by golly and this is so I should have that.
And then as we go and here again you'll see most of the same information we saw before.
You'll see that this one ties to an e-mail address as opposed to a website and it actually defines what
type of key it is in all this.
There's that CRL distribution point which is going to be important later.
And now if we take a look at the Certification Path here you'll see that it actually has quite a bit
of path to it.
So that's the route authority and there's two levels of intermediate before we actually get to me on
this particular system.
OK.
So those are the certificates that are in my computer that's great but where do these certificates come
from.
Well most of these come actually from the web browsers themselves.
When you install a web browser it has a whole bunch of certificates already in their root and intermediate
ready to go in fact people fight hard to get Firefox or Internet Explorer or whatever to include their
particular certificate.
So it's a big deal.
Also these certificates these root and intermediate certificates are updated all the time.
I always get terrified when somebody isn't updating their systems because a big part of the had hadn't
certificate update.
So that's where those certificates come from.
And remember the certificates that are on your system for the most part are only there as root and intermediate
so that when you get that e-bay certificate or whatever it is you can do a quick comparison of that
certificate based on the information on the certificates you already have to verify whether it's good.
OK.
But if I'm a web server or if I want to do e-mail where do those certificates come from.
Well first of all it is trivial to get an certificate generation tool.
They come with Windows and with Linux you could always make your own certificate.
Now obviously no one signing it.
So it's a unsigned certificate but you could always make your own very very quickly and if you try to
plug that into a web server or send an e-mail it's going to be a big sign pops up saying whew.
This is an unsigned certificate.
Do you want to continue.
Yes.
No.
So if you want a signed certificate you go online to sign Comodo Wattie whoever's out there and you
usually have to buy these things.
So you go online and you set some stuff up in there and you hand them your public key and other information
you hand that all to then you hit enter and then hand him a credit card usually and then you get a certificate
the certificates in the old days used to come through the mail and you'd actually have to import them
into your computer today for the most part what you do is it will say your certificates ready and you
go to Web site and you click on something and literally through the connection your new certificate
is brought into your web server or your email client whatever it might be.
The challenge we have here is that certificates don't have a standardized format like Word documents
or Excel spreadsheets.
What we do have is the PKC s numbers.
So what we want to do right now is I'm going to go back into the system and let's do a little exporting
and take a look at PKC Yes.
OK so what I've got here is what back in and taking a look at my certificates now.
In this particular case I'm actually showing you my personal certificates that I went ahead and downloaded
these I went to Comodo and got these certificates.
Now what I want to show you is how we can export a certificate.
So in this case I'm going to just pick one of these arbitrarily and I'm going to hit export and Windows
comes with this nice little wizard.
Now here's the first big question it asks Do I want to export the private key or not because remember
a certificate by definition does not have the private key so I'm going to say no do not export the private
key.
Now it's given me some options as to how I want to export it.
Now some of these versions up here are used for more specific versions but in general we're going to
go to PKC as Number 7 so this is a PKC s 7.
And if there are other certificates in the certification path I can add those here as well if I want
to.
All right.
So remember the goal here is that we're going to export this to a file I'm going to call it Fred.
And I believe it's pointed to my desktop.
Let's see what happens.
Yeah yeah yeah.
Export was successful.
Outstanding.
All right so you can see that I now have exported this certificate.
This is not something you need to do very often.
It's a rare situation where you need to export.
It is done for backup.
We see people do it for that reason.
And back in the old days if you wanted to move to a new system or something like that you could do a
manual export as well.
And if you see we can click on it and actually look at the certificate itself just like we saw before.
So I can put that on a thumb drive.
Do anything I want.
So what I want to do now is I'm going to export it again.
Except this time I'm going to do a little bit differently.
This time we're going to say yes export the private key.
Remember the private key is precious and it's something that should be secured under a password and
encrypted and all that.
And believe me that's going to happen.
So you'll see that when we export the certificate as well as the corresponding private key.
So it's really two things we're exporting.
It says PKC 12.
So make sure you know PKC is 12 is really more than just a certificate.
Delete the private key.
The export is successful if we were actually moving this to a new system we would want to do that extended
properties is just extra stuff I'm going to skip that for right now.
Now look what it's asking me to do right here it's asking me to punch in a password because we don't
want this thing to be casually laying on my desktop where anybody can grab my private key so we're going
to go ahead and hit next and we've got to give it another name I'm going to call it timmy
and the export was successful.
So let me close this and let's take a look.
In this case first of all you see the icons totally different it has a affects a file extension.
And if I double click this I can't really just look at it because it's a package and what is going to
try to do is actually import it into my system.
I don't want to do that because it's already in there but it's important that you remember PKC A7 is
a way that we store certificates as individual files PKC as 12 is not only the certificate but also
the private key and it's actually a package OK so let's go ahead and take one more quick look at the
certificate through here and I have to go through all this because I said do the entire Certification
Path.
Now I want to go back into details
and let's take a look at this right here CRL distribution points and you'll notice that that is a path
CRL is something very important.
Let's talk about that CRL stands for Certificate revocation list.
The CRL what you notice is a path is a really really important part of our whole Piquet system.
You see the challenge that we have here is that your computer is counting on certificates that are actually
already stored locally on your system.
And because of the nature of hashing and encryption and all that it's hard they're pretty trustworthy
but things can happen.
What if Verizon went out of business oh I don't even think about that or what if Comodo got captured
by evil terrorists and they were doing naughty things.
The problem we have is that we can have real time problems with our certificate so we need some kind
of way to check and see if even the local certificates are bad.
To say nothing about the certificate that we just got from eBay.
So this is important.
So what we have originally was the CRL.
And if you remember that that was just a little your L that gives your system the opportunity to very
quickly lose pretty fast.
You can go to that you are ill and literally there's a list of a bunch of thumbprint numbers and these
numbers which are unique to individual certificates say this one's bad and even says why they're bad
so you can read.
This is all done automatically.
You don't have to do anything but your browser or whatever it might be will go in and using the CRL
do a quick check to make sure everything's copacetic and happy.
Now C-R our are great.
We've used them for decades.
But the problem with C-R else is that it can take up to.
Depends on who you're talking to.
But as much as 24 hours to react to a bad certificate in some fashion.
Now keep in mind when I say that I'm not talking about expired certificates I'm not talking about certificates
that you know you go to www.youtube.com and all of a sudden the certificates for w w w dot e boy dot
com or something like that.
Those are issues that are built in to your system to take care of that.
I'm talking about something that wouldn't normally be caught a certificate that's been revoked for some
reason or another and that's where the sea trials really have a bit of a problem because it can take
so long.
And that's why we turn to a more modern feature called Online certificates status protocol or CSP.
CSP were very similar early to CRL but the one big differences that's pretty much real time is virtually
real time in terms of being able to check whether a certificate is good or not.
See our are starting to fade and CSP is the beautiful thing that we're using today so that my friends
is a very light touch and certainly good enough for security plus level touch on public key infrastructure.
Public infrastructure is amazing stuff and it's really gives us that first opportunity to dig in and
understand certificates.
Make sure you know why we have certificates.
Make sure you know what a certificate looks like.
Make sure you know what a Certification Path is.
Some of the things that we mentioned within the certificate are important and make sure you know your
PKC Yes cause you're gonna see it on the exam.