Recently, I have stumbled upon the basic understanding about PKI work-in-action process. I have looked at major articles about the principles but still I feel quite dumb to understand this process. I understand that PKI is not for „My blog„ but for the sake of simplicity lets walk through simple example “My e-Shop” (for example apache and php) and simple concepts. I wrote some statements that might be vague or even wrong but that’s what I want to know about the process of PKI:
“My e-Shop” as a company needs to be “certified” at some third party CA. That means I need to buy some kind of 1 year membership at that CA, and then, they will register “My e-Shop” at their systems and issue me some stuff like a certificate and a pair of unique public and private keys. Will I get some certificate-file?
Issued certificate is filled with my info and public key and stored in some file at my webserver. The certificate verifies that “My e-shop” is not a bureau of thieves.
Every time users access “My e-shop” through “https” their browsers “silently” checks the presented certificate of “My e-shop” with the one that is registered at CA.
When some user enters “My e-shop” via https the following happens: “My e-shop” (webserver) gets the public key (PK1) of the user. The server silently presents the certificate of “My e-shop” to the user, so the users gets the public key (PK2) of “My e-shop”. After some silent checking the browser of the user validates presented certiticate and a secure pipe is established.
When a user sends a request via secure pipe the requests is encrypted with public key of “My e-shop”. Then, web server decrypts the request with its private key. Then, web server sends encrypted response with a public key of the user. At the end, the browser of the user decrypts the response with his private key.
Taking these question by question:
(1) “My e-Shop” as a company needs to be “certified” at some third party CA. That means I need to buy some kind of 1 year membership at that CA, and then, they will register “My e-Shop” at their systems and issue me some stuff like a certificate and a pair of unique public and private keys. Will I get some certificate-file?
Yes. Also, this varies from CA to CA - some CAs, a 1 year membership and a valid credit card is enough (not to hard to get, even if you happen to be a band of theives), some CAs require a certain amount of paperwork to verify that you are who you say you are. A CA is only as good as it's customer-verification process, so generally the more onerous the process, the better (and more expensive) the CA.
When you have paid your money and done your paperwork, then you and the CA will generate at least 2 things:
You get back one of two things:
(2) Issued certificate is filled with my info and public key and stored in some file at my webserver. The certificate verifies that “My e-shop” is not a bureau of thieves.
yes... sort of. Your webserver will need both the signed certificate AND the key pair. The key pair is used as part of the SSL handshake to the end user, and that exchange proves that you are in posession of the key pair, and not some band of theives that got their hands on the certificate. This is why you want to protect the key pair.
(3) Every time users access “My e-shop” through “https” their browsers “silently” checks the presented certificate of “My e-shop” with the one that is registered at CA.
For some definition of "silent". A baseline browser checks that the certificate: - is currently valid - is signed by a CA that the browser trusts (or it either denies access or gives you an annoying popup)
Browser add ons will go farther and do things like full path checking (all the way to the self signed root) and certificate status checking. The higher the risk of the info being shared over the pipe, the more checking needs to happen.
(4) When some user enters “My e-shop” via https the following happens: “My e-shop” (webserver) gets the public key (PK1) of the user. The server silently presents the certificate of “My e-shop” to the user, so the users gets the public key (PK2) of “My e-shop”. After some silent checking the browser of the user validates presented certiticate and a secure pipe is established.
OK - stuff is going off the rails here.
For details, check the SSL protocol - the handshake section will give you the hard facts.
The browser and the webserver do pass back and forth information that lets them create a session encryption key. The browser does generate some starting material used to set up the session, but it is not "the public key of the user (PK1)". The user does not need to have PKI credentials UNLESS the server has been configured for client authentication. In a regular, run of the mill My e-Shop, the server has a PKI credential, the browser is generating some key material on the fly for just that one session. The server has absolutely no idea who the browser user is, SSL-wise - all of the user identification comes from a password or something else at the application level.
NOTE: This is for a regular commercial transaction. The higher the risk, the greater the protection. High risk transactions frequently require client authentication.
(5) When a user sends a request via secure pipe the requests is encrypted with public key of “My e-shop”. Then, web server decrypts the request with its private key. Then, web server sends encrypted response with a public key of the user. At the end, the browser of the user decrypts the response with his private key.
Not quite. This is the weeds - a developer of a web application is relatively abstracted from all of this. But - the session content is not encrypted with asymmetric keys - that would be excruciatingly CPU intensive. The PKI of the server and the on-the-fly browser generated handshake data are used to exchange the session encryption key. Part of this is that the client selects and sends a secret key encrypted in the server's public key. Since only the server has the private key, only the server can decrypt the data sent by the client.
This secret key is symmetric (exactly which algorithm is also part of the handshake) and is used for the remainder of the session.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With