In this lesson I want to explain certificate services.
So PKI is the keyword, it stands for the public key infrastructure, and it is about the infrastructure
that provides public private keys that can be used to secure services.
Now in this case the private key is what is supposed to be private, and it is used by
a server to prove its identity, and the public key is handed out to clients for secure communication.
The client uses the public key, and that allows you to send encrypted traffic which next can
be decrypted with the private key on the server.
To guarantee the authenticity of a public private key pair the keys need to be signed,
and the signing is happening by an external certificate authority, or the CA.
You can also use self-signed certificates, and self-signed certificates are keys that
are not signed by a commonly known certificate authority, but by an internal CA that is not
commonly trusted.
Now that sounds as if it doesn't make sense, it does, because if you are working with certificates
on your own site, why would you pay an external certificate authority for the reliability
of your certificates?
But for your own clients only, you can take care of this reliability internally.
So self-signed certificates are quite common, but be aware that if ever your browser encounters
self-signed certificates, it will issue a warning.
It's very likely that you have already seen warnings like this while browsing the internet
to unreliable web servers.
So how do we use certificates?
Well, a message digest is a fixed-size numerical representation of the contents of a message.
And this message digest is calculated by a hash function.
And in secure communication, the sender typically generates a message digest, which is encrypted
with the private key of an asymmetric key pair.
Asymmetric key pair, that means that the sender and receiver are not using the same key.
So the sender generates the message with the private key, and the result is a digital signature.
And next, the signature is decrypted by the receiver to verify the identity of the sender.
And next, an encrypted channel has been established.
Let me show you how this works.
So let me give you an overview of how TLS certificates are used.
Let's say we have a client and we have a web server.
And I'm going for a simplified overview here.
Now, when you are going to send your sensitive data to the web server, you want to make sure
that the transport is secured.
So how does that work?
Well, the web server has a private key.
And when you initialize traffic with the web server, you are going to make sure that you get the web server public key.
The public key is mathematically related to the private key.
So they belong together.
But the first question is, how are you going to be sure that this public key is legit?
Well, that is because of the certificate authority, the CA.
And the certificate authority has signed this public key in the PKI certificate.
And in case you want to know how the certificate authority has done that, well, that is easy,
with their own public-private key.
So the public key has been signed with, let's call it CAPR, the certificate authority private key.
And because certificate authorities are supposed to be well-known, when you receive this signed public key,
because of the fact that the certificate authority is known, you can check that it is legit.
Because browsers and such have the certificate authority public key on board and they can verify that it's okay.
So you can trust it.
Now, once you know that you can trust your web server, you can establish a secure channel.
And in this secure channel, you are going to encrypt the data with the web server public key.
And then the data arrives at the web server.
And only with the web server private key, the data can be decrypted.
And that is what's happening between common HTTPS traffic, for instance.