We know that before the client establishes a session with the server, the client sends the request first, then tpc/ip the three handshake, and then the client establishes an SSL session with the server side.
Session Process:
A--> Server Side
B--> Client
The first step: AB both discuss the use of what encryption algorithm, how to encrypt and so on. Step two: A send a certificate to B, in order to make B believe him. Step Three: B believe, generate the symmetric key, send the request page to a. Finally, a uses the key sent by B to encrypt the request and respond to B.
Since B is to verify the identity of a, it introduces a third party authority, the CA, that can issue a certificate. and b is trusting the CA, so B owns the CA's certificate.
Then, a generates a pair of public keys, sends it to the CA for signing (which can be understood as stamped), gets the certificate, returns it to itself, and configures the server so that it can use the certificate. and b after receiving a certificate, use the CA certificate saved on the host to verify.
Next, we will implement the authentication of the private CA.
Preparatory work:
Two hosts, one to do CA (172.16.13.1), one to do the Web server side (172.16.13.2).
[Note--172.16.13.2 host must be configured to complete the Web server]
Steps:
The production of CA certificate (on CA's host)
1, to see if the installation of OpenSSL software
# Rpm-qa OpenSSL
2. Generate self-signed certificate
"Complete in/etc/pki/ca directory"
(1) Generate private key
(2) Generate a self-signed certificate
Because the certificate is generated is required to fill in some countries, provinces and other information. This information is written directly to its default profile and will not be filled in later.
"Edit/etc/pki/tls/openssl.cnf," find around 136 lines:
"Generate a Visa book"
To use a CA as a private CA, you also need to modify the default path in the/etc/pki/tls/openssl.cnf file:
and create the directories that the CA needs to work.
Thus, the CA certificate is created to complete