Digi. Certificates: Key pairs usages
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 can also be used to encrypt message, and private key are can also be used to decrypt message.
If the whole session need to be encrypted, two pairs of keys are 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 key to server through key pairs, then both sides communicate with the symmetric key rather than the public/private key method.
[HW quote]
-----------original post ends, hereafter are added at DEC/07/2017---------
Some knowledge stated below is learned from huawei.
something is not right in the above lines so I deleted the wrong parts with a deleting line.
Yes, verify a certificate sent from others has 2 ways, one is stated above: it is already listed in the implicit list of trusted certificates; the other way is to validate the certificate with the certificate that it claims to be the signer of it. The claimed certificate should either be in the implicit list of trusted certificate or be sent together with it. The certificate that sent together should also be validated with a certificate that it claims to be the signer of it.... Thus a chain of certificates should be validated one by one, till we get a certificate which can be validated by an implicit trusted certificate installed on our local machine. Thus the problem of trust solved.
And a certificate stored on a local machine can have 3 states: anchor, blacklist, store-only. An anchor certificate is trusted by system, a blacklisted certificate is untrust by system, store-only certificate keeps the certificate for use of chained certificate by other applications.
Linux: according to manpages of x509, trust, update-ca-trust, we have 2 locations to store certificate: /etc/ca-certificates/ & /usr/share/ca-certificates/. The latter's priority is lower than the former. Inside each location, there is a trust-source folder, inside which we have 2 folders: anchors & blacklist. store-only certificates be located just in the trust-source folder. To install a certificate we can mv it in the appropriate folder, or use trust to install/remove: (it is then installed in the /etc/ca-certificates/ as format p11-kit)
sudo trust anchor somecert.cer sudo trust anchor --remove somecert.cer
to view the content of a certificate:
openssl x509 -inform DER -in somecert.cer -text|less
to extract the installed cert as pem file in the extracted folder:
sudo mv somecert.cer /etc/ca-certificates/trust-source/anchors/ update-ca-trust extract
Windows: certlm.msc/certmgr.msc..
About more info of x509/DER formatted certificates: see manpages of x509. Any certificate should specify its specific range of used domains, only the specified domains in the given x509 formatted certificate can be verified with the certificate.
