对话安全性的证书
会话开始后，Service Broker 使用远程服务绑定查找用于该会话的证书。本主题介绍 Service Broker 如何确定会话所用的证书。
查找对话的证书
Service Broker 首先查找会话的远程服务绑定，然后选择在该绑定中指定的用户所拥有的一个证书。
查找绑定时，Service Broker 对数据库进行检查，以查找为会话指定目标服务名的绑定。
选择证书时，Service Broker 查找远程服务绑定中指定的用户所拥有的证书中过期日期最晚的证书。Service Broker 不考虑尚未生效的证书、已过期的证书或未标记为可用于启动对话的证书。有关证书的详细信息，请参阅 CREATE CERTIFICATE (Transact-SQL)。
如果没有远程服务绑定，或者远程服务绑定的用户没有可用于启动对话的有效证书，则 Service Broker 无法加密会话中的消息。如果没有绑定并且数据库包含 Broker 配置服务，则 Service Broker 将通过该服务请求一个绑定。如果数据库中没有 Broker 配置服务，或者 Broker 配置服务不提供远程服务绑定，则在加密设为 ON 时将推迟会话，在加密设为 OFF 时会话继续，不进行加密。有关详细信息，请参阅确定对话安全性类型。
远程授权和对话安全性
Service Broker 对话安全性使用证书进行远程授权。当对话使用对话安全性时，会话中的每个参与者所发送的第一条信息，都包含使用发送用户的私钥进行加密的标头信息，以及使用接收用户的公钥进行加密的标头信息。消息的内容是用会话密钥加密的。会话密钥本身也经过了加密，只有使用接收用户的私钥才能解密它。
如果消息的接收方可以成功地解密该消息，这表示该接收方拥有相应的密钥，这样便可以确认会话中每个参与者的身份。在数据库中安装证书便创建了与持有私钥的数据库之间的信任关系。
实际上，使用本地用户的私钥加密标头即是询问“远程数据库是否信任本地数据库？”远程数据库必须含有相应的公钥，才能解密该标头。使用远程数据库中用户的公钥加密标头即是询问“本地数据库是否信任远程数据库？”远程数据库必须含有相应的私钥，才能解密该标头。为了安全和高效，Service Broker 同时询问这两个问题。但是，消息是结构化的，因此接收方必须能够对这两个问题都予以肯定，才能正确响应消息。
此策略背后的推理十分简单。如果远程数据库可以解密使用本地数据库的私钥进行加密的标头，则该远程数据库包含相应的公钥，即该远程数据库信任本地数据库。如果远程数据库可以解密使用本地数据库的公钥进行加密的标头，则该远程数据库包含相应的私钥，即本地数据库信任该远程数据库。只要妥善保管好私钥不致泄露，则只有会话中所涉及到的两个数据库才可以成功交换该会话的消息。
.gif "注意") 注意 |
|---|
只能安装来自可信来源的证书。请勿分发私钥。 |
完全对话安全性在第一次交换消息时将在两个方向上验证身份。对于使用匿名对话安全性的会话，发起方将验证目标数据库是否包含所需的私钥。但是，对于匿名对话安全性，目标数据库不验证发起方的身份；而目标服务的宿主数据库必须允许 public 固定数据库角色向该服务发送消息。
必须在两个方向上都交换消息后，本地数据库才能认为远程数据库的身份得到了确认。只有本地数据库包含远程数据库中证书的正确公钥，验证才能发生。
对于会话的每一方所发送的第一条消息，Service Broker 都会在其中包含以下标头：
一个“服务对”安全标头，它包含消息所用证书的有关信息。服务对安全标头是用拥有该服务的用户的私钥签名的。
一个“密钥交换密钥”，用于加密 128 位的会话密钥，会话密钥用于加密消息正文。密钥交换密钥是用远程用户的公钥加密的。
对于使用匿名安全性的对话，服务对安全标头是未加密的。消息本身仍然是加密的，密钥交换密钥是用目标数据库中安全主体的公钥加密的。在这种情况下，第一次返回的消息不包含密钥交换密钥、服务对安全标头或加密的会话密钥。
当 Service Broker 本身生成一条消息以响应一条传入消息（例如，一个错误或确认）时，无论对话是使用完全安全性还是匿名安全性，该消息都使用此传入消息的会话密钥。