标签：nbsp provided keep inf dig hold eve pair mmu
In short, we have some sort of algorithms to gen pair of private and public keys. The public key is stored in a certificate and the private key is usually kept by server(usually the CA wont keep the private key). The certificate is generated by C.A. (certificate authority) from given info and public key provided by people/company. When some person need to send message secretly, they use the given certificate‘s public key to encrypt the message before send, only servers keep the right private key can decrypt it. But how do we know if the certificate is officially generated by the correct site? 2 ways, one way is to put the certificate under the implicit trust certificate list(it is pre-installed with OS/browser). The second is to prove it is trusted by the list of certificate sites mentioned. It‘s going to ask the trusted listed authorities the correct certificate of the given site, and the authority will respond a cypher text of the requested certificate as a signature of the requested certificate, this cypher text is encrypted with its private key. Anyone hold the CA‘s certificate can decrypt it and check the expected value of the certificate is correct. Then we get a correct certificate of the site from our trusted CA.
Root CA‘s private keys are usually kept physically isolated.
Each private key needs to be backupped and kept isolated from peering. Private keys shall be parted and distributed to several systems.
[quote]
Public key are used to encrypt message, and private key are used to decrypt message.
If the whole session need to be encrypted, two pair of keys is needed.
Usually client side of pair of keys are generated randomly and not be verified through trusted list of CA.
Also, if no need high encryption, client side send a symmetric code to server through key pairs, then both sides communicate with the symmetric code rather than the public/private key method.
Digi. Certificates: Key pairs usages
标签：nbsp provided keep inf dig hold eve pair mmu
原文地址：http://www.cnblogs.com/sansna/p/6198394.html
