CIA 和授權可以為您做什么Windows Communication Foundation 中的選擇傳輸安全性消息安全性憑據標準綁定中的默認安全性發(fā)現客戶(hù)端標識通過(guò) HTTPCFG 安裝證書(shū)總結Windows Communication Foundation 可以執行大量繁重的任務(wù)，以便使您的服務(wù)能夠更輕松地提供大多數分布式系統所需的基本安全功能。大多數標準 Windows? Communication Foundation 綁定都提供三大保護功能：保密性、完整性和身份驗證（或稱(chēng) CIA，因為我喜歡這樣稱(chēng)呼）。如果您不需要這些保護，您必須將其關(guān)閉，因為它們在默認情況下處于打開(kāi)狀態(tài)。
CIA 和授權可以為您做什么
那么每種保護各具有什么作用呢？保密性可確保對消息進(jìn)行加密，使竊聽(tīng)者無(wú)法閱讀消息的內容。完整性可確保您使用密鑰哈希對每個(gè)消息的內容執行校驗和操作，以便知道消息仍保持原樣，未被篡改，也沒(méi)有被攻擊者成批注入到消息流中。當然，如果連接的另一端是敵人，則對連接進(jìn)行加密將毫無(wú)意義！因此，為了交換用于提供保密性和完整性的密鑰，Windows Communication Foundation 使用了一種身份驗證握手機制，它不僅可幫助客戶(hù)端和服務(wù)發(fā)現這些密鑰，還可以幫助他們發(fā)現彼此的標識。
一旦服務(wù)知道了客戶(hù)端的標識，它即可以授權客戶(hù)端執行各種操作。授權是通過(guò)檢查客戶(hù)端提供的聲明來(lái)進(jìn)行的。Windows Communication Foundation 提供了多種可擴展性?huà)煦^，允許您應用所選擇的授權策略，并檢查聲明的有效性。您可以使用現有的組件，比如 ASP.NET 成員身份、角色提供程序和授權管理器 (AzMan)，有關(guān)它們的更多信息，您可以在
msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager 上找到。您還可以結合 Thread.CurrentPrincipal、IPrincipal.IsInRole 和 PrincipalPermissionAttribute 一起使用基于標準 .NET 角色的安全基礎結構?；蛘?，您可以在 Windows Communication Foundation 中以 IAuthorizationPolicy 接口為中心使用授權策略框架，該接口可以對聲明實(shí)施精細的控制。您也可以審核客戶(hù)端的操作。您會(huì )發(fā)現，Windows Communication Foundation 本身已經(jīng)可以為您審核許多安全事件。
構建安全系統時(shí)，透明性很重要。如果您內置于系統中的安全功能相對并不透明，用戶(hù)會(huì )失去興趣，并通常會(huì )避免使用這些功能。作為從事安全工作的人，我的最得意之作總是看不見(jiàn)摸不著(zhù)的，這雖然讓人有點(diǎn)傷感，但卻是事實(shí)！Windows Communication Foundation 可幫助您以多種方式實(shí)現透明性，但最重要的方式之一是通過(guò)單一登錄。通過(guò)緊緊綁定到 Windows 域身份驗證，您可以利用用戶(hù)的域登錄，并減少其需要跟蹤的憑據的數量。Windows Communication Foundation 還使得可以方便地使用聯(lián)合標識，即使合作伙伴組織使用您公司提供的 Web Services，他們也可以獲得同樣的單一登錄體驗。
安全性的另一個(gè)重要方面是在面對輸入錯誤時(shí)所表現出的可靠性。Windows Communication Foundation 對此也沒(méi)有有效的應對手段，因此，您仍然有責任預先假定所有輸入都是錯誤的，直到事實(shí)證明并非如此。同時(shí)也不要想當然地認為，已通過(guò)身份驗證的用戶(hù)不會(huì )向您發(fā)送不正確的輸入！即使您僅為內部客戶(hù)端提供服務(wù)，您也必須保持可靠性。我在這里談?wù)摰氖堑钟舻哪芰?，比?SQL 注入、格式不正確的資源名稱(chēng)（如文件路徑），在某些情況下甚至包括跨網(wǎng)站編寫(xiě)腳本。當您聽(tīng)到有人說(shuō)“Windows Communication Foundation 默認情況下是安全的”這樣的話(huà)時(shí)，您應理解為他們可能說(shuō)的是 CIA。
返回頁(yè)首Windows Communication Foundation 中的選擇
Windows Communication Foundation 將我們以前單獨使用的無(wú)數通信堆棧的最佳功能融匯在了一起。這意味著(zhù)您在提供服務(wù)時(shí)，可以有許多種選擇，其中的一些選擇會(huì )影響安全性。最重要的選擇涉及使用什么綁定。您是否想讓消息排隊？您是否需要互操作性或原始性能？
時(shí)刻記住您不需要僅僅做出一種選擇。您可以通過(guò)您希望的任意數量的綁定提供一個(gè)單一的服務(wù)合同；僅需為每個(gè)綁定提供一個(gè)不同的端點(diǎn)即可。例如，您可以通過(guò) HTTPS 提供一個(gè)非常簡(jiǎn)單的 WS-I Basic Profile 綁定，以便與供應鏈中現有的合作伙伴進(jìn)行互操作。同時(shí)，您可以提供一個(gè)為域中的本地客戶(hù)端使用 Windows 身份驗證的 TCP 端點(diǎn)。但只有在用戶(hù)未在合同中指定 ProtectionLevel 屬性（使用 ServiceContract、OperationContract、MessageHeader 等）時(shí)，此方式才有效。
典型的標準綁定具有大量用于調節安全設置的不同“旋鈕”，但每個(gè)綁定都已經(jīng)過(guò)仔細調整，可以為您會(huì )遇到的大多數情形提供安全的默認設置。您需要最頻繁切換的兩個(gè)“旋鈕”是安全模式（傳輸與消息安全性）和客戶(hù)端憑據類(lèi)型。這些“旋鈕”非常重要，因此，讓我們研究一下如何正確使用。
返回頁(yè)首傳輸安全性
在為 Windows Communication Foundation 綁定配置安全性時(shí)，您需要做出的第一個(gè)選擇，是需要在傳輸級別還是在消息級別提供 CIA。每種選擇各有其優(yōu)缺點(diǎn)。
如果您為傳輸安全性配置 wsHttpBinding，Windows Communication Foundation 將不會(huì )為您的消息提供 CIA。您需要通過(guò) HTTPS 運行，以便安全套接字層 (SSL) 可以提供這些保證。事實(shí)上，除非提供 HTTPS URI，否則 Windows Communication Foundation 將會(huì )拒絕設置連接。如果您正在 IIS 內部托管，您將需要為網(wǎng)站安裝一個(gè) SSL 證書(shū)。另一方面，如果您正在自己的進(jìn)程中托管，并直接使用 HTTP.SYS，您將需要以編程方式或通過(guò)命令行工具 HTTPCFG.EXE 向 HTTP.SYS 注冊一個(gè)證書(shū)。
使用 SSL 有充分的理由。因為 SSL 已經(jīng)存在了這么多年，密碼員已經(jīng)以它為對象做過(guò)大量分析，而且管理員已經(jīng)弄清了如何對它進(jìn)行部署。還有現成的硬件可以對其進(jìn)行加速，以減輕您的服務(wù)器的 CPU 負荷。最重要的是，如果您的目標是實(shí)現跨平臺的廣泛訪(fǎng)問(wèn)，則如今再沒(méi)有比通過(guò) SSL 使用 WS-I Basic Profile 更好的選擇了（當然，這也意味著(zhù)使用 basicHttpBinding 替代 wsHttpBinding）。
對于客戶(hù)端和服務(wù)都使用 Windows Communication Foundation 的域環(huán)境中的內部通信，具有傳輸安全性的 netTcpBinding 可能是一種更好的選擇。由于它具有二進(jìn)制編碼，所以性能當然要好得多；又因為默認情況下它只使用 Kerberos，因此，盡管要配置服務(wù)主體名稱(chēng)，也無(wú)需證書(shū)（請參閱“配置服務(wù)主體名稱(chēng)”提要欄）。
返回頁(yè)首消息安全性
可以不在傳輸級別提供 CIA，而選擇通過(guò)使用消息安全性將這些細節向下推入到 SOAP 消息自身中。這種方式的主要優(yōu)點(diǎn)是靈活性。WS-Security 和用于確保 SOAP 消息安全的相關(guān)規范非常靈活；只要客戶(hù)端和服務(wù)都允許，您可以使用所希望的任何安全憑據類(lèi)型，在很大程度上不受傳輸影響。實(shí)際上，您甚至可以發(fā)送多個(gè)憑據，在涉及中間方的委派方案中，這很有意義。
以 wsHttpBinding 為例。默認情況下，它使用消息級別的安全性，假定服務(wù)和客戶(hù)端使用 Windows 憑據對其自身進(jìn)行身份識別和身份驗證。默認情況下，對正文和大部分標頭都進(jìn)行簽名，以維護消息的完整性（具體而言，它會(huì )對所有 WS-Addressing 標頭進(jìn)行簽名，并對所有應用程序標頭進(jìn)行加密和簽名），并對正文加密。查看消息跟蹤信息的攻擊者可以毫無(wú)阻礙地看到 SOAP 信封，但 SOAP 正文會(huì )包含一個(gè) <EncryptedData> 元素，其中填滿(mǎn) base64 編碼加密文本。
Windows Communication Foundation 還允許您混合使用傳輸和消息安全性。在這種模式下，會(huì )在傳輸級別提供保密性和完整性以及服務(wù)器的身份驗證（因此會(huì )加密整個(gè)字節流，而不僅僅加密消息正文），而客戶(hù)端身份驗證會(huì )在消息級別執行。然后，客戶(hù)端可以使用 WS-Security 來(lái)發(fā)送它所需要的任何形式的憑據。這種模式可以使您獲得傳輸安全性所具有的性能和成熟度，并可提高選擇憑據的靈活性。
返回頁(yè)首憑據
選擇了傳輸安全性或消息安全性或其混合模式后，假定您未選擇“None”（無(wú)）安全模式，下一個(gè)主要決策就是客戶(hù)端和服務(wù)將要使用的憑據的形式。Windows Communication Foundation 只向您提供一個(gè)“旋鈕”（即客戶(hù)端憑據類(lèi)型），從而簡(jiǎn)化了此決策過(guò)程，該“旋鈕”還決定每種方案下有意義的服務(wù)憑據類(lèi)型?？蛻?hù)端憑據至少有五個(gè)選項，雖然在某些環(huán)境下有些選項可能會(huì )不可用。
第一個(gè)選項為“None”（無(wú)），選定時(shí)，客戶(hù)端為匿名客戶(hù)端。在這種情況下，服務(wù)會(huì )使用證書(shū)來(lái)確保服務(wù)客戶(hù)端的標識。這與您通過(guò) HTTPS 訪(fǎng)問(wèn)標準網(wǎng)站時(shí)遇到的情況類(lèi)似。
第二個(gè)選項為“UserName”（用戶(hù)名），選定時(shí)，客戶(hù)端將提供用戶(hù)名和密碼。同樣，在這種情況下，服務(wù)會(huì )使用證書(shū)向客戶(hù)端驗證其標識。此證書(shū)還將用于加密客戶(hù)端的憑據，以便傳輸給服務(wù)。
下一個(gè)選項是“Windows”，選定時(shí)，客戶(hù)端和服務(wù)都會(huì )使用 Windows 帳戶(hù)進(jìn)行身份驗證。Windows Communication Foundation 將會(huì )就 Kerberos 或 NTLM 進(jìn)行協(xié)商，如果存在域，則優(yōu)先選擇 Kerberos（NTLM 實(shí)際上不會(huì )向客戶(hù)端驗證服務(wù)的身份，而只會(huì )向服務(wù)驗證客戶(hù)端的身份）。如果您想要使用 Kerberos，則必須讓客戶(hù)端根據配置中的服務(wù)主體名稱(chēng)驗證服務(wù)的身份。如果您要在域環(huán)境中為客戶(hù)端構建服務(wù)，您應明確地為其提供發(fā)送 Windows 憑據的選項。這將允許客戶(hù)端使用其現有的 Windows 登錄信息，從而讓您免費實(shí)現單一登錄！
“Certificate”（證書(shū)）是另一個(gè)選項，選定時(shí)，服務(wù)將具有一個(gè)證書(shū)，客戶(hù)端也具有一個(gè)其自己的證書(shū)。這在當今的許多企業(yè)對企業(yè)方案中十分常見(jiàn)。
最后，“IssuedToken”允許您的服務(wù)從安全性令牌服務(wù) (STS) 接受一組簽名的聲明。雖然開(kāi)始時(shí)您對此會(huì )不易接受，但此選項在以后將會(huì )很重要，因為它可以啟用聯(lián)合標識方案和 InfoCard。當您與某個(gè)合作伙伴組織聯(lián)合時(shí)，您將允許該合作伙伴通過(guò)任何合適的技術(shù)對其自己的用戶(hù)進(jìn)行身份驗證。在最理想的情況下，這將允許該合作伙伴組織中的用戶(hù)通過(guò)單一登錄使用您的服務(wù)，即便他們并不與您使用同一個(gè) Active Directory 域，或不受您的信任。該合作伙伴組織中的用戶(hù)需要使用 STS 進(jìn)行身份驗證，而 STS 可以發(fā)出一個(gè)簽名的安全聲明標記語(yǔ)言 (Security Assertion Markup Language, SAML) 令牌。您既可以直接接受該令牌，也可以要求將該令牌呈送給您組織中的 STS，以便讓其評估該合作伙伴的聲明，并發(fā)出第二個(gè)您可以使用的 SAML 令牌。
在任何一種情況下，您的服務(wù)都會(huì )收到您信任的 STS 發(fā)出的一個(gè)安全令牌。Windows Communication Foundation 將會(huì )驗證該簽名和此信任關(guān)系，并將該令牌中的聲明通過(guò) ServiceSecurityContext 的實(shí)例呈送給您的服務(wù)。只需讀取 ServiceSecurityContext.Current 靜態(tài)屬性，您的服務(wù)即可以在對請求進(jìn)行處理的同時(shí)訪(fǎng)問(wèn)此對象。之后，您可以使用此信息來(lái)執行授權和審核。
聯(lián)合的好處在于，它可以自動(dòng)驗證合作伙伴之間現有的信任關(guān)系：進(jìn)行聯(lián)合時(shí)，無(wú)需向合作伙伴組織中的每個(gè)用戶(hù)都發(fā)布影子 Windows 帳戶(hù)或證書(shū)。自動(dòng)驗證這些關(guān)系還有很多好處。自動(dòng)化可以減少錯誤和延遲，這意味著(zhù)您所獲得的有關(guān)該合作伙伴組織中的用戶(hù)的信息將更準確和更新。這還可以降低 IT 人員的成本，因為他們不再需要為合作伙伴提供用戶(hù)帳戶(hù)。聯(lián)合標識是一個(gè)重要的主題，在以后的專(zhuān)欄文章中，我將花費更多的時(shí)間進(jìn)行探討。
返回頁(yè)首標準綁定中的默認安全性
三種最為流行的標準綁定分別為 basicHttpBinding、wsHttpBinding 和 netTcpBinding。最簡(jiǎn)單且最具互操作性的是 basicHttpBinding，它支持 WS-I Basic Profile。必須注意的是，這一特定的綁定和其他大多數綁定一樣，默認情況下并不提供 CIA。由于 SSL 的普及，確保此綁定安全的最流行的方法是只在 HTTPS 上運行。為此，您將需要調整該綁定，以便讓 Windows Communication Foundation 知道您將要使用傳輸安全性：
<bindings><basicHttpBinding><binding name="MyBindingTweaks"><security mode="Transport"><transport clientCredentialType="None"/></security></binding></basicHttpBinding></bindings>
完成此操作后，最簡(jiǎn)單的部署方法是在 IIS 中進(jìn)行托管，并為您的虛擬目錄打開(kāi) SSL 支持（這意味著(zhù)，如果尚未為網(wǎng)站安裝證書(shū)，則將安裝證書(shū)）。請注意，在這種特定的綁定中，我已經(jīng)允許了匿名客戶(hù)端。如果您要在 IIS 中進(jìn)行部署，并計劃要求提供客戶(hù)端證書(shū)，請將 clientCredentialType 更改為 Certificate。
下一個(gè)綁定 wsHttpBinding 默認情況下會(huì )對 WS-Security 和 WS-SecureConversation 使用消息安全性。默認的客戶(hù)端憑據類(lèi)型為 Windows，這使得起步非常容易；它僅使用客戶(hù)端和服務(wù)的 Windows 登錄信息作為憑據。此綁定上最常用的安全性調整，是將其切換為使用 TransportWithMessageCredential。下面您將使用 HTTPS 端點(diǎn)來(lái)實(shí)現加速的服務(wù)器身份驗證、完整性和保密性，同時(shí)，客戶(hù)端憑據會(huì )留在 SOAP Security 標頭中以保持靈活性。這項技術(shù)的優(yōu)點(diǎn)之一，是通過(guò)傳輸對整個(gè) SOAP 信封加密，包括所有標頭。它還允許您使用硬件加速，從服務(wù)器的 CPU 中卸載安全套接字層/傳輸層安全性 (SSL/TLS)。不過(guò)，也存在著(zhù)一些缺點(diǎn)，比如缺乏消息級別的端對端安全性。下面顯示如何運用此綁定調整在消息級別接受 SAML 令牌，例如：
<binding name="MyBindingTweaks"><security mode="TransportWithMessageCredential"><transport clientCredentialType="None"/><message clientCredentialType="IssuedToken"/></security></binding>
如果您想讓基于 Windows 的 Intranet 上的 Web Services 具有原始速度，則您應認真考慮使用 netTcpBinding，它可以使用 XML Infoset 的專(zhuān)用二進(jìn)制編碼對每個(gè) SOAP 信封進(jìn)行編碼，而不使用傳統的尖括號編碼。默認情況下，此綁定會(huì )將傳輸安全性與 Windows 憑據結合使用，并且非常高效。這也許是您最接近于 DCOM 的性能和安全模型的情況。默認綁定會(huì )將傳輸安全性與協(xié)商的身份驗證結合使用。該協(xié)商會(huì )嘗試使用 Kerberos，但如果行不通，它會(huì )回退并使用較舊的 NTLM 協(xié)議。Kerberos 是域環(huán)境下的理想選擇；為了使用它，您需要讓服務(wù)和客戶(hù)端均在域帳戶(hù)下運行。您還需要為您的服務(wù)配置一個(gè)服務(wù)主體名稱(chēng) (SPN)，如本頁(yè)的提要欄中所示?？蛻?hù)端將需要調整其端點(diǎn)說(shuō)明，以包括服務(wù)的標識，即服務(wù)所注冊的 SPN。（并不總是需要此 SPN。如果服務(wù)托管于 IIS 中并在 NetworkService 帳戶(hù)下運行，則會(huì )自動(dòng)提供 SPN。Windows Communication Foundation 會(huì )從客戶(hù)端上的 URL 中準確推斷出該 SPN。）下面是在配置中實(shí)現這一目的語(yǔ)法。請注意 servicePrincipalName 元素：
<client><endpoint name="MyEndpoint" address="net.tcp://..."binding="netTcpBinding" contract="IFoo" ><identity><servicePrincipalName value=‘MyService/MyMachine‘ /></identity></endpoint></client>
當客戶(hù)端的 Windows Communication Foundation 的探測功能讓域控制器為服務(wù)提供 Kerberos 票證時(shí)，它將使用 MyService/MyMachine 名稱(chēng)來(lái)請求該票證，而且，只要此 SPN 已經(jīng)在 Active Directory 中為該服務(wù)的域帳戶(hù)注冊，就會(huì )給客戶(hù)端發(fā)布票證，并會(huì )使用 Kerberos。否則，如果 Kerberos 可用，但 SPN 不正確，則會(huì )引發(fā)一個(gè)異常。如果不能使用 Kerberos 向服務(wù)進(jìn)行身份驗證，則客戶(hù)端將不會(huì )獲得票證（白白浪費到域控制器的往返操作），并且您將進(jìn)入 NTLM 回退模式，這意味著(zhù)會(huì )為回退協(xié)商進(jìn)行更多的往返操作。另外，您將無(wú)法獲得 Kerberos 的功能，比如委托客戶(hù)端憑據的潛在能力。
返回頁(yè)首發(fā)現客戶(hù)端標識
在用于發(fā)現客戶(hù)端標識的各種方法中，最簡(jiǎn)單的方法是利用 Thread.CurrentPrincipal，它是用于探測的 .NET 中（比如 ASP.NET 中）的標準方法，而 Windows Communication Foundation 會(huì )將已經(jīng)過(guò)身份驗證的客戶(hù)端的標識傳遞到您的代碼中。這個(gè)頗為神奇的靜態(tài)屬性會(huì )根據向它提出請求的線(xiàn)程返回不同的值。這將允許您通過(guò)多個(gè)線(xiàn)程為不同的客戶(hù)端提供服務(wù)，其中每個(gè)線(xiàn)程都可以看到所服務(wù)的客戶(hù)端的標識而不會(huì )相互干擾。
如果您已經(jīng)將 Windows 指定為 clientCredentialType，則 Thread.CurrentPrincipal 將指向 WindowsPrincipal，并且您可以通過(guò)調用 WindowsPrincipal.IsInRole 來(lái)查看用戶(hù)屬于哪個(gè)組。此處唯一的一個(gè)小問(wèn)題是，由于安全方面的原因，您應該指定完全限定的組名稱(chēng)，其中包括對該組進(jìn)行定義的域或計算機，如下所示：
IPrincipal client = Thread.CurrentPrincipal;if (client.IsInRole(@"MyMachine\Managers")) {// 允許客戶(hù)端進(jìn)行管理}
我在構建基于這樣的組進(jìn)行授權的系統時(shí)，通常會(huì )添加某一級別的間接尋址，它可以通過(guò)查看配置提供所使用的組的計算機名或域名。這樣做會(huì )大大簡(jiǎn)化部署過(guò)程。
我將在以后的專(zhuān)欄文章中進(jìn)一步討論授權 — 關(guān)于這個(gè)主題，要說(shuō)的內容很多。請注意：Windows Communication Foundation 并不總會(huì )設置 Thread.CurrentPrincipal。只有在使用 PrincipalPermissionAttribute 時(shí)或在配置要求時(shí)，才會(huì )進(jìn)行設置。您應該使用 ServiceSecurityContext.Current.WindowsIdentity 來(lái)獲取客戶(hù)端的標識（如果可用），而不應依賴(lài)于 Thread.CurrentPrincipal。下面顯示了在需要記錄客戶(hù)端操作的情況下如何獲取客戶(hù)端的名稱(chēng)：
string clientAccountName =ServiceSecurityContext.Current.WindowsIdentity.Name;
如果客戶(hù)端在使用已發(fā)布的令牌憑據進(jìn)行身份驗證，您將需要使用 ServiceSecurityContext.AuthorizationContext 來(lái)拾取這些詳細信息。如果客戶(hù)端在使用未映射到 Windows 帳戶(hù)的證書(shū)進(jìn)行身份驗證，則可以使用 ServiceSecurityContext.Current.PrimaryIdentity。我打算以后進(jìn)一步探討這些主題。
返回頁(yè)首通過(guò) HTTPCFG 安裝證書(shū)
如果您想要使用 SSL，但并不打算將您的服務(wù)托管于 IIS 中，則您可以使用 HTTP.SYS 來(lái)提供 SSL 支持。為了使用 HTTP.SYS 中的 SSL 支持，您需要告訴 HTTP.SYS 在何處查找其 SSL 證書(shū)；您可以使用 HTTP API 實(shí)現這一目的，或使用 HTTPCFG.EXE 從命令行調用這些 API。默認情況下并不安裝 HTTPCFG.EXE，但您可以通過(guò)安裝操作系統安裝磁盤(pán)的 SUPPORT\TOOLS 目錄中的支持工具，來(lái)獲得該工具。
如果您想將證書(shū)與 HTTP.SYS 結合使用，您需要在本地計算機存儲中而不是在用戶(hù)存儲中安裝 HTTP.SYS。您可以通過(guò)運行“證書(shū)”Microsoft? 管理控制臺 (MMC) 管理單元來(lái)執行此操作；添加該管理單元時(shí)，請確保在詢(xún)問(wèn)時(shí)選擇“計算機帳戶(hù)”，然后選擇部署了該服務(wù)的計算機，或者，如果您已經(jīng)登錄部署了該服務(wù)的計算機，則選擇“本地計算機”。然后將證書(shū)導入到該計算機的“個(gè)人”存儲中?！皞€(gè)人”存儲是您通常放置您擁有其私鑰的證書(shū)的位置。
查看證書(shū)的屬性并獲取證書(shū)的 SHA-1 指紋（請參閱圖 1）。這是 HTTP.SYS 查找證書(shū)的方式，因此您將需要此值?，F在，在部署了該服務(wù)的計算機的命令提示符下執行以下命令，這是您使用 HTTP.SYS 注冊證書(shū)時(shí)要使用的命令：
HTTPCFG add ssl -i 0.0.0.0:4242 31883a61892d8c...
圖 1 證書(shū)指紋
您看到的第一個(gè)數字是一個(gè) IP 地址 0.0.0.0，它表示該計算機可能具有的所有 IP 地址。如果要綁定到特定的 IP 地址，您應該使用那個(gè) IP 地址的值來(lái)代替。接下來(lái)是服務(wù)要偵聽(tīng)的端口號。最后是指紋（如果是從證書(shū)查看器中復制此內容，您需要刪除字節之間的空格）。為簡(jiǎn)便起見(jiàn)，我只顯示了該哈希的第一部分，因為它有 20 個(gè)字節長(cháng)。
