服務通訊的憑證Service Communications Certificates

適用於:Windows Server 2016、Windows Server 2012 R2、Windows Server 2012Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

聯盟伺服器需要服務通訊憑證使用案例是 WCF 郵件安全性。A federation server requires the use of service communication certificates for scenarios in which WCF message security is used.

服務通訊認證需求Service communication certificate requirements

服務通訊憑證必須符合下列需求,請使用 AD FS:Service communication certificates must meet the following requirements to work with AD FS:

  • 服務通訊憑證必須包含伺服器的驗證增強金鑰使用 (EKU) 擴充功能。The service communication certificate must include the server authentication enhanced key usage (EKU) extension.

  • 必須存取所有的憑證鏈結中的服務通訊憑證根憑證撤銷清單 (CRLs)。The certificate revocation lists (CRLs) must be accessible for all the certificates in the chain from the service communication certificate to the root CA certificate. 根 CA 必須也會受信任的任何聯盟伺服器 proxy 和信任此聯盟伺服器的網頁伺服器。The root CA must also be trusted by any federation server proxies and Web servers that trust this federation server.

  • 主體名稱所使用的服務通訊憑證必須符合同盟服務中的名稱同盟服務的屬性。The subject name that is used in the service communication certificate must match the Federation Service name in the properties of the Federation Service.

服務通訊憑證部署注意事項Deployment considerations for service communication certificates

設定服務通訊的憑證,讓所有聯盟伺服器都使用相同憑證。Configure service communication certificates so that all federation servers use the same certificate. 如果您要部署的聯盟網路 Single-Sign-On (SSO) 設計,我們建議您服務通訊的憑證,CA 公開發行。If you are deploying the Federated Web Single-Sign-On (SSO) design, we recommend that your service communication certificate be issued by a public CA. 您可以要求,並安裝這些透過 IIS 管理員 snap\ 中的憑證。You can request and install these certificates through the IIS Manager snap-in.

您可以使用 self\ 簽署、 在實驗室測試環境聯盟伺服器成功服務通訊的憑證。You can use self-signed, service communication certificates successfully on federation servers in a test lab environment. 不過,production 環境中,我們建議您從公開 CA 取得服務通訊的憑證。However, for a production environment, we recommend that you obtain service communication certificates from a public CA. 您應該會為何不使用 self\ 簽署服務通訊的憑證動態部署的原因如下:The following are reasons why you should not use self-signed, service communication certificates for a live deployment:

  • A self\ 簽章 SSL 憑證必須新增至受信任的根在市集上每個聯盟伺服器資源合作夥伴組織中。A self-signed, SSL certificate must be added to the trusted root store on each of the federation servers in the resource partner organization. 時,這單獨不可危害資源聯盟伺服器,信任 self\ 簽署的憑證會增加電腦的攻擊,它會導致安全性弱點如果憑證簽署不可靠。While this alone does not enable an attacker to compromise a resource federation server, trusting self-signed certificates does increase the attack surface of a computer, and it can lead to security vulnerabilities if the certificate signer is not trustworthy.

  • 它會建立不正確的使用者體驗。It creates a bad user experience. 戶端將會收到安全性警示提示嘗試存取聯盟的資源顯示以下訊息: 「 安全性憑證有不受信任的公司。 」Clients will receive Security Alert prompts when they try to access federated resources that display the following message: "The security certificate was issued by a company you have not chosen to trust." 這會是預期的行為,是因為不受信任的 self\ 簽署的憑證。This is expected behavior, because the self-signed certificate is not trusted.

    注意

    必要時,您可以使用群組原則來手動向下推入 self\ 簽署的憑證存放區受信任的根每個 client 電腦嘗試存取 AD FS 網站上運作周圍此條件。If necessary, you can work around this condition by using Group Policy to manually push down the self-signed certificate to the trusted root store on each client computer that will attempt to access an AD FS site.

  • Ca 提供其他 certificate\ 為基礎的功能,例如私密金鑰保存、 續約,以及撤銷,不提供的 self\ 簽署的憑證。CAs provide additional certificate-based features, such as private key archive, renewal, and revocation, that are not provided by self-signed certificates.