Some understanding gaps about Public Key Infrastructure workflow

Question

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:

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?

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.

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.

   1. What about users? Do their browsers generate local public+private keys when entering “My e-shop” via https?

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.

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.

Answer 1

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:

• A public/private key pair. Often this is generated by YOU, not by the CA. The quality of how you have generated and stored your key pair is also a factor in determining how much another entity can trust your website. Generally, for identification certificates (like SSL server certs) it's a good idea to have the customer (My e-Shop) generate the key.
• You'll send a certificate request in a standard format (example: PKCS10) to the CA. It will include a bunch of information about My e-Shop and the public key.
• The CA company will check your paperwork and make sure you are you. Then it will use it's CA to digitally sign a certificate for you. That certificate has a bunch of the information you just provided, some extra info that the CA provider sets for you, your public key and the digital signature generated by cryptographically binding all the aforementioned data with the CA's private key.

You get back one of two things:

• just the certificate (if you generated your own key pair)
• the certificate and the key pair - if the CA generated the key pair for you

(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.

• What about users? Do their browsers generate local public+private keys when entering “My e-shop” via https?

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.

Answer 2

Your steps are incorrect on a couple of different levels. Let me restate them, hopefully in a clear manner.

1. Your site needs to have an SSL certificate from a trusted third-party CA (Verisign, etc.). You will need to purchase it from them. You will generate the public/private key pair, provide them with your public key (it is part of the certificate request) and they will generate the certificate.

2. The certificate contains the domain name of your site, your public key, and some other additional information. It does not verify anything, particularly not that your site isn't "a bureau of thieves". All it typically certifies is that you own the domain name for which you are requesting a certificate. It does not mean that your site is trustworthy by any means.

3. When a user accesses your site via HTTPS, your server will send the certificate down to the client's browser. At no time does the client communicate with the CA to validate your certificate.

3.1. Typically, end users (clients, customers) would not need their own certificates and private keys. This is called mutually-authenticated SSL, and involves both parties (your customers and your site) having a certificate. This is rarely (if ever) used in e-commerce sites.

1. When a user accesses your site via HTTPS, your server sends down the certificate to the client browser. The client will use this to perform an SSL Handshake. This handshake between the browser and your site is what establishes the secure tunnel. The specifics of the handshake protocol are more technical than you need.

2. When a request is sent to the server over the SSL tunnel, the server handles it the same way it would any other request. The only difference is that the communication between your customers and your server is encrypted. Your webserver will likely handle the decryption of the data from the request and present it to your webserver for processing. Likewise, the response data is returned back to the client in an encrypted form via the SSL Tunnel.

Better?

Answer 3

Regarding point 3:

As far as I know this is not completely correct. Since there is not really a kind of established live testing infrastructure (in comparison to services like DNS), the web server will send the complete chain of certificates to the browser. On the other hand the browser or operating system is delivered with a set of trusted root certificates (which need to be updated sometimes, windows update, new browser releases, etc.)

And yes the browser will be supposed to generate an "untrusted" key pair, since under normal circumstances a standard user will not generate his or her own certificate.

Regarding point 5:

Also this is not completely the truth. Computation of asynchronous encryption requires a great amount of time. So the RSA algorithm is just used to exchange keys for faster synchronous encryption standards (i.e. AES, 3TES).