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.
