- Your web browser downloads the web server’s certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.
- Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server’s certificate was indeed signed by the trusted certificate authority.
- The certificate contains the domain name and/or ip address of the web server. Your web browser confirms that the address listed in the certificate is the one to which it has an open connection.
- Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.
Note that the certificate authority (CA) is essential to preventing man-in-the-middle attacks. However, even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic, since they have no way to gain access to your shared symmetric key.
如果服务器要求鉴别客户身份，则检查签署客户证书的CA是否可信。如果不在信任列表中，结束本次会话。如果检查通过，服务器用自己的私钥解密收到的pre-master secret，并用它通过某些算法生成本次会话的master secret。
To see a complete worked example of this process using Firefox connecting to amazon.com, seemoserware.com/2009/06/first-few-milliseconds-of-https.html
cert = identity_info + public key + digit signature(CA signed identity-info)
my another post in Chinese about cert.
4 questions need to be address during the authentication:
- Has the Digital Certificate been issued/signed by a Trusted CA?
in browser, already CA installed. In java, import others from `cacert` file
- Is the Certificate Expired – checks both the start and end dates
make sure it is not expired
- Has the Certificate been revoked? (Could be OCSP or CRL check)
either from a Certificate Revocation List (CRL), OR from a Online Certificate Status Protocol (OCSP).
- Has the client provided proof of possession?
sign the message’s hash with its private key and send along with the cert so that the receiver could use the public key to decrypt the message hash and do a hash to the message and then compare.
Client certificate(2 way SSL)
Client also need cert from CA(same or another) as well as the private key. Server need the CA which signed the client cert in its
During the handshake, the client not only send the cert to the server, but also something signed by its private key. More specific: according to RFC5246 7.4.8. Certificate Verify in which client sign the handshake messages in the `Certificate Verify` message of the TLS handshake so that the server can verify it against the public key sent in the client certificate. Without this step, no client-certificate authentication would be taking place.