在安全HTTPS中提及到的密钥协商（安全通讯前的准备工作）中，包含了身份认证和密钥协商2大过程如下，其中SSL协议包含记录协议和握手协议，在握手协议中协商通讯传输的的对称加密密码、压缩算法、加密算法等，具体的步骤如下：
Step1
s客户端往服务器端发ClientHello消息
消息特点：该消息是客户端连接服务器端时发送的第一个消息。
消息构成：
(1). 使用的TLS协议版本。
(2). 随机数；用于计算对称加密时的“主密码”。
(3). 会话ID；重连时有用，可为空。
(4). 加密算法列表；客户端支持的加密算法列表，并按照客户端的偏好从前往后排。
(5). 压缩算法列表；客户端支持的压缩算法列表，并按照客户端的偏好从前往后排。
(6). 扩展信息。
消息作用：用于发起会话、交换随机数、协商加密算法、压缩算法等。
Step2
服务器端验证ClientHello消息，主要验证：
(1) 消息格式是否合法；
(2) 能否至少支持客户端所列举的一个加密算法和一个压缩算法等。
验证不通过则发送消息断开会话，验证通过则执行下一步。
Step3
服务器往客户端发送ServerHello消息。
消息特点：该消息是服务器收到ClientHello后返回给客户端的第一个消息。
消息构成：
(1). 使用的TLS协议版本。
(2). 随机数；用于计算对称加密时的“主密码”(这个随机数是服务器发送给客户端的,跟第一步骤的随机数不同,第一个是客户端发送给服务的)
(3). 一个加密算法；服务器从客户端的加密算法列表中选中的一个加密算法。
(4). 一个压缩算法；服务器从客户端的压缩算法列表中选中的一个压缩算法。
(5). 会话ID；新建的唯一的会话ID。
(6). 扩展信息。
消息作用：用于交换随机数、确定加密算法、压缩算法等。
Step4
服务器往客户端发送Certificate消息。
消息特点：该消息必须在ServerHello发送完后立即发送。如果是匿名协商，则无须发该消息。
消息构成：
(1). 证书列表；服务器的证书必须为证书列表的第一个，其后为签发服务器证书的证书，依次类推，最后一个证书为根证书签署的证书。根证书不在证书列表中，它是通过其他途径给到客户端的。(好多时候是浏览器预装好的)
消息作用：发送服务器证书，或者证书链。
Step5
服务器往客户端发送ServerKeyExchange消息。
消息特点：
(1). 该消息必须在Certificate发送完后立即发送（如果是匿名协商，则该消息紧跟在ServerHello后）。
(2). 该消息只有当Certificate消息无法提供足够信息让客户端完成“预主密码”交换时才需要。
消息构成：
(1). 密钥交换算法
消息作用：该消息用于发送密钥交换算法给客户端。客户端可利用这些算法和服务器端完成“预主密码”的交换。
Step6
服务器往客户端发送CertificateRequest消息。
消息特点：
(1). 非匿名的服务器可通过该消息来要求客户端发送证书验证其身份。
(2). 如果发送该消息则该消息在ServerKeyExchange发送完后立即发送(如果该次交互不发送ServerKeyExchange，则该消息紧跟Certificate消息)
消息构成：
(1). 证书类型列表；客户端的证书类型必须是证书类型列表中一种。
(2). 签名和哈希算法列表；列举服务器所支持的签名算法和哈希算法。
(3). CA名字列表；服务器只接受的列表中所列出的CA所发行的证书，其他证书无法验证。
消息作用：请求客户端发送证书验证其身份。(只有双向认证才需要,即服务器也需要认证客户端)
Step7
服务器往客户端发送ServerHelloDone消息。
消息特点：
消息构成：
(1). 无消息内容。
消息作用：该消息用来告诉客户端ServerHello以及附属消息都已发送完毕。发完该消息后服务器等待客户端消息。
Step8
客户端往服务器端发送ClientCertificate消息。
消息特点：
(1). 该消息仅当收到服务器CertificateRequest时才发送，即服务器要求验证客户端。
(2). 如果发送该消息，则该消息必须是客户端收到ServerHelloDone消息后发往服务器的第一个消息。
消息构成：
(1). 证书列表。
消息作用：发送客户端证书让服务器认证。(只有双向认证才需要,即服务器也需要认证客户端)
Step9
客户端往服务器端发送ClientKeyExchange消息。
消息特点：
(1). 如果有ClientCertificate消息，则该消息必须紧跟其后发送；如果无ClientCertificate消息，则该消息是收到ServerHelloDone消息后发往服务器的第一个消息。
(2). 消息用RSA算法或者 Diffie-Hellman参数来协商预主密码。
(3). 采用RAS加密的协商预主密码时，先生成一个长的随机数，由该随机数和客户端的TSL版本号构成一个结构体，用服务器证书的公钥（从服务器证书获得）对结构体进行加密，并把加密后的数据发给服务器。
(4). Diffie-Hellman参数协商比较复杂，暂不讨论。
消息构成：因加密算法而异。
消息作用：协商预主密码
Step10
客户端往服务器端发送CertificateVerify消息。
消息特点：
(1). 该消息只有当客户端证书有签名能力时(Tenfy:即有客户端证书，且证书是公钥和私钥都有的)发送，其它情况不发送（不含固定Diffie-Hellman参数的证书都有签名能力）。
(2). 该消息必须在ClientKeyExchange发送完后立即发送。
(3). 该消息采用客户端证书中的私钥信息进行加密。
消息构成：
(1). 把该消息之前的所有消息作为参数，用私钥对其进行签名得出一份数据，该数据即为消息体。
消息作用：通过签名方式，验证客户端身份。
Step 11
服务器用服务器私钥解密ClientKeyExchange消息得 “预主密码”。服务器和客户端用相同的算法计算“主密码”。主密码计算是根据预主密码、ClientHello中的随机数、ServerHello中的随机数得到的。计算好主密码后双方各向对方发送一个ChangeCipherSpec消息：
消息特点：
(1). 该消息必须在所有握手消息发送完之后，在Finished消息发送之前发送。
(2). 该消息必须在接收完所有握手消息之后，在接收Finished消息之前收到。
消息构成：
(1). 确认消息。
消息作用：确认采用刚才协商好的压缩算法、加密算法、主密码等来传输后继数据。
Step12
任意一方收到ChangeCipherSpec消息后告诉自己的Record Layer由读等待状态转为读状态，并采用新方式来传递数据。并往另外一端往发送Finished消息。
消息特点：
(1). 该消息是收到ChangeCipherSpec后立即发送的。
(2). 该消息是首次采用刚才协商好的压缩算法、加密算法、主密码等来传输的数据。
消息构成：
(1). 把前面大部分的握手消息作为参数，用相同的算法计算得到的一个值。
消息作用：完成压缩算法、加密算法等的协商，开始转入应用层数据传输。
Step13
双方验证收到的消息，验证通过则开始应用层数据传输，否则断开。
通讯过程中必须严格按上述说明来发送和接收消息。接收方接收消息后一旦发现：(1)消息遗漏，(2) 消息次序不对，(3) 消息格式（如加密格式）有误，(4) 消息内容有误，(5) 自身致命错误等，接收方立即通过Alert Protocol往发送方发送ErrorAlert消息，告诉对方终止此次会话。如果是能容忍的错误，则不发任何消息，以免对方主动断开会话。
若干重要验证说明
- 客户端验证服务器的Certificate消息。主要验证内容为：
(1). 服务器证书使用日期是否有效。
(2). 发行服务器证书的CA是否可靠。
(3). 发行者的公钥能否解开服务器证书上的“发行者数字签名”。
(4). 服务器证书上的名称（如域名）是否和服务器实际名称匹配等（PHP中可以选择是否验证该选项）。
(Tenfy: 这里可以看出,客户端验证服务的时候,只需要验证对应服务器证书的有效性即可,无需验证对应服务器是否拥有跟该证书一致的私钥)
- 服务器验证客户端的CertificateVerify消息。主要验证内容为：
(1). 用客户端公钥能否解开客户端私钥加密的消息。
(Tenfy:服务器验证客户端时候，还需要验证是否拥有跟证书对应的私钥)
- 服务器验证客户端的ClientCertificate消息。主要验证内容为：
(1). 客户的证书使用日期是否有效。
(2). 为客户提供证书的CA 是否可靠。
(3). 发行CA 的公钥能否正确解开客户证书的发行CA的数字签名。
(4). 检查客户的证书是否在证书废止列表（CRL）中。
