使用MicrosoftSOAPToolkit2.0建立安全Web服务

使用 Microsoft SOAP Toolkit 2.0 建立安全 Web 服务

Kirill Gavrylyuk

测试组长，Web 数据 SOAP 组

Microsoft Corporation

2001年7月

摘要： Microsoft SOAP Toolkit 2.0 提供一个灵活的框架，可以为各种 Intranet 和 Internet 解决方案构建可伸缩的 Web 服务。在这两种方案中，安全性都是建立可靠服务的重要因素。SOAP Toolkit 2.0 支持基于 IIS 安全基础结构的 Internet 安全性。本文介绍了如何使用 Microsoft SOAP Toolkit 2.0 建立安全解决方案。

目录

简介

重要规则

身份验证

代理支持和身份验证

SSL 和客户端证书

身份验证问题

疑难解答

其它信息

简介

与任何分布式协议相同，成功的 SOAP 应用程序的关键在于获得安全性权限。SOAP 标准不指定任何安全性机制，而是将安全处理委派给传输层。对 SOAP Toolkit 2.0 而言，传输层是 HTTP。在 HTTP 上运行的 SOAP 基本上是一个 Web 应用程序，与其它在 IIS 上运行的 ASP 或 ISAPI 应用程序很相似。SOAP 的身份验证、授权和加密机制与您通常使用的 Web 应用程序完全相同。如果熟悉 Web 安全性，也就了解了 SOAP 安全性。如果对 Web 应用程序不够熟悉，本文将为您提供充分的入门知识背景。每个主题都介绍的非常详细。如果需要更详细的信息，请参见 MSDN Library 或由 Michael Howard、Marc Levy 和 Richard Waymire 编著的《设计 Microsoft Windows 2000 基于 Web 的安全应用程序》。

重要规则

根据《设计 Microsoft Windows 2000 基于 Web 的安全应用程序》中阐述的观点，我们首先从概述建立安全 Web 服务应遵守的重要规则开始。安全 Web 服务可归纳为以下七类：

身份验证

授权

审核

保密

完整性

可用性

认可

身份验证是一个实体（也称为主题）验证另一个实体是否符合它所声称的身份的过程。SOAP Toolkit 2.0 支持以下身份验证方法：

基本

摘要式

Kerberos

Windows NTLM

SSL 客户端证书

基于 SOAP 头的身份验证

代理身份验证

本文档介绍如何配置服务器端和客户端使用上述身份验证方法。

授权是为经过身份验证的用户提供资源访问权限的机制。只要使用 SOAP Toolkit 建立的 Web 服务基于 IIS，这些服务就可以利用 IIS 支持的授权机制。本文档也将讲述用户应注意的一些问题。

审核的目的是为了收集有关对 Web 服务的成功和失败请求的信息。可以使用 IIS 审核功能和 SOAP Toolkit 跟踪功能实现这一目的。本文档没有介绍这方面的内容，您可以参考 IIS 文档、netmon 日志和 SoapServer 对象的 SOAP Toolkit 帮助。

保密是指确保攻击者看不到客户端与服务器之间的通信信息。完整性是指保护数据不被删除或更改（不管是恶意还是不慎）的能力。为了实现保密和完整性，SOAP Toolkit 允许使用安全套接字层 (SSL) 加密数据。本文档将介绍如何启用 IIS 上的 SSL 支持以及如何将其用于客户端。

可用性确保不会拒绝合法用户对请求的资源的访问。可用性技术的示例包括负载平衡以及硬件和软件的故障转移。SOAP Toolkit 已成功通过了 Microsoft Application Center 负载平衡软件的测试。

认可是一种技术，为发生的操作提供证据以防止客户端在事务处理中欺诈或否认。SOAP Toolkit 采用 IIS 提供的认可功能。本文档不对认可进行介绍。

身份验证

本节介绍了 SOAP Toolkit 支持的身份验证方法，包括其优点和缺点，以及如何对其进行设置。还介绍了 SOAP Toolkit 在支持平台上的已知局限性，以及服务器具有多个可用身份验证方案时 SOAP Toolkit HTTP 连接器的行为。

身份验证握手是如何进行的？每个身份验证握手都是如下开始：

客户端发出页面请求。

服务器返回状态 401“拒绝访问”和一组 HTTP 头。

WWW 验证它支持的每一个身份验证方法。

如何使用 SoapClient 验证自身？如果 Web 服务要求身份验证（基本、摘要式、NTLM 或 Kerberos），需要为 SoapClient 提供用户名和密码，以将其传递到 Web 服务。也可以使用 SoapClient.ConnectorProperty 包完成此操作：

dim SoapClient

set SoapClient = createobject(“MSSoap.SoapClient”)

SoapClient.mssoapinit(“

“)

SoapClient.ConnectorProperty(“AuthName”) = “username”

SoapClient.ConnectorProperty(“AuthPassword”) = “userpwd”

Quote = SoapClient.GetQuote()

注意：使用 SOAP Toolkit 2.0 时，只有在调用远程方法时才必须设置 SoapClient 上的 ConnectorProperties。

如果包含服务描述的 wsdl 文件所在的虚拟目录也要求身份验证，可以在 URL 内传递用户名和密码：

SoapClient.mssoapinit

(“

username:userpwd@your-server/webservice/service.wsdl “)

人们往往错误地认为将用户名和密码放入 URL 是不安全的。事实并非如此。在发送 HTTP 请求之前，客户端 HTTP 代码将分析 URL，移出用户名和密码，并在身份验证握手时使用此用户名和密码。事实上，代码：

SoapClient.ConnectorProperty(“AuthName”) = “username”

SoapClient.ConnectorProperty(“AuthPassword”) = “userpwd”

Quote = SoapClient.GetQuote()

与下列代码的功能相同（假设 WSDL 文件 service.wsdl 指向自身）：

SoapClient.ConnectorProperty(“EndPointURL”)=

username:userpwd@your-server/webservice/service.wsdl”

Quote = SoapClient.GetQuote()

虚拟目录设置如何要求身份验证？若要在服务器上更改特定虚拟目录的身份验证设置，请执行下列操作：

在 IIS 4.0 和 IIS 5.0 上，用鼠标右键单击虚拟目录，单击“属性”，然后单击“目录安全性”选项卡。

在“匿名访问和身份验证控制”之下，单击“编辑”。将出现以下两个选项：

匿名访问

匿名访问不是身份验证方法。Windows 2000 和 NT4 要求用户在访问任何资源之前验证自身，这种情况下，IIS 使用一个特殊帐户作为匿名 Web 用户（默认为 IUSR_machinename）。可以单击“匿名访问编辑”按钮更改此默认匿名 Web 用户的帐户或其密码。

注意：小心不要将特权帐户用作匿名 Web 用户帐户。若要将虚拟目录设置为要求身份验证，需要清除“匿名访问”标记。

基本身份验证

若要将虚拟目录设置为要求基本身份验证，需要：

转至“属性”/“目录安全性”/“编辑匿名访问验证控制”菜单。

取消选中“匿名访问”。

启用“基本身份验证”。将显示一条警告消息。如果要继续使用基本身份验证，请单击“确定”。

单击“基本身份验证编辑”按钮。输入域名。如果要使用默认域名，请输入“\”（不加引号）。

缺点：基本身份验证是非常不安全的。用户名和密码以不加密的 Base64 编码形式通过线路传输。问题不仅在于攻击者能访问基本身份验证保护的资源，他们还能够获取您的用户名和密码的实际值，并用来访问其它更安全的资源。使用 SSL 连接会更安全一些，因为 SSL 握手在身份验证握手之前发生。这样，可以通过安全连接传送用户名和密码。

优点：基本身份验证是 HTTP 1.0 协议的一部分，是得到最广泛支持的身份验证方案。

结论：基本身份验仅当与 SSL 功能共同使用时才是一个好的解决方案。如果希望您的服务具有安全性和高互操作性，请使用本方法。

摘要式身份验证

这是一个相对较新的方法，是 HTTP1.1 协议的一部分，但没有被 Web 服务器广泛采用。对于 Windows，它只在出现 Windows 2000 之后才被采用。若要在 IIS 5.0 上设置摘要式身份验证，请执行下列步骤：

转至“属性”/“目录安全性”/“编辑匿名访问”和“身份验证控制”菜单。

取消选中“匿名访问”。

启用“摘要式身份验证”。将显示一条警告消息。如果要继续使用摘要式身份验证，请单击“确定”。

使用摘要式身份验证具有以下要求：

运行 Windows 2000 Server 的系统位于 Active Directory 域。

在域控制器上安装 iissuba.dll 文件。该 DLL 在匿名访问和摘要式身份验证期间发挥作用。

在 Active Directory 设置中使用摘要式身份验证的所有帐户的日志记录都启用“使用可逆加密存储密码”选项。这是对 Active Directory 中帐户密码的纯文本副本进行摘要式身份验证访问时所必需的。这样，可确保存储这些密码的服务器是非常安全的。

缺点：如果摘要式身份验证不与 SSL 一起使用，将不能保护资源免于重复攻击。目前尚未在其它 HTTP 客户端和服务器中被广泛采用。在 IIS 5.0 上的实现具有局限性，如果通过摘要式身份验证登录到服务器，标识将无法委派到其它服务器。这就将服务器限制为服务器方案。

优点：摘要式身份验证简单，可能会越来越普及。它比基本身份验证更安全，因为尽管仍可能遭到重复攻击，但攻击者无法获得访问其它资源所要求的用户名和密码的实际值。

结论：摘要式身份验证可以用于保护通过 Web 服务公开到 Internet 的低价值资源。在 SSL 上使用基本身份验证可以获得更好的性能，因为 SSL 速度慢，但不会象基本身份验证那样将用户名和密码暴露给攻击者。

Windows 集成身份验证 (NTLM)

Windows 集成身份验证（IIS 4 中的 Windows 请求/响应身份验证）在 Windows 2000 和 NT4 上表现为不同的方法。在具有 IIS 4 的 NT 4 下，它描述为 NTLM 身份验证。若要将 IIS 服务器设置为要求 Windows 集成身份验证（在 IIS 5 上）或 NTLM（在 IIS 4 上），请完成基本或摘要式身份验证步骤 1 和 2，并在步骤 3 中选择相应的复选框。

NTLM 身份验证（NT LAN Manager 或 Windows 请求/响应身份验证）是本机 Windows 身份验证方案。如果未指定用户名/密码，将使用当前登录用户凭据。通过 Intranet 访问时，如果用户已经登录的域与 Web 服务器的域相同，而且使用自己的凭据，则这些用户不必重新进行身份验证。在 NTLM 握手过程中，客户端用服务器（请求）发送的随机值散列密码，然后将此散列（响应）发送给服务器。这意味着密码不会通过线路显式发送。人们通常错误地认为 NTLM 只能用于 Intranet 解决方案，不应用于 Internet。实际上，NTLM 可以用于 Internet，只不过用于 Intranet 时速度更快，因为它依赖于 Windows 登录过程。若要同时传送域名和登录名称，请使用 SAM 帐户名称：

SoapClient.ConnectorProperty(“AuthName”) = “DOMAIN\username”

缺点：NTLM 只能用于 Windows。与基本和摘要式身份验证方案一样，它只对客户端进行身份验证。使用 NTLM 时，服务器上的模拟线程无法将自己的权限委派给另一台服务器。这限制了 NTLM 身份验证在“服务器至服务器”方案中的使用；但仍可以在这种方案中使用基本和摘要式身份验证。NTLM 不能通过代理工作。

优点：NTLM 比基本和摘要式身份验证更安全，因为它不容易受到重复攻击。由于依赖 Windows 登录过程，因此在 Intranet 方案中速度很快。

结论：推荐将 NTLM 用于“客户端至服务器”Intranet 解决方案。也可用于限制为 Windows 体系结构的公司 Internet 解决方案。

Kerberos 身份验证

Kerberos 身份验证是在 Windows 2000 中出现的。当指定 IIS 5 使用 Windows 集成身份验证时，IIS 5 和 SoapClient HTTP 连接器通过协商协议确定是使用 NTLM 还是使用 Kerberos。如果在 Windows 2000 上运行 SoapClient，则使用 Kerberos，否则使用 NTLM。指定 SoapClient 上用户凭据时所应用的规则与 NTLM 相同。

缺点：仅 Windows 2000 平台支持 Kerberos。Kerberos 要求具有一个可向其请求服务票证的 KDC 服务器。通常，人们不想将自己的 KDC 服务器公开于 Internet。因此，Kerberos 通常只限于 Intranet 应用。默认情况下，只有服务器的 NetBIOS 名称在 Kerberos KDC 中进行了注册。如果您希望请求票证时使用 IIS 服务器的 DNS 名称，则必须在 KDC 中注册 DNS 名称。

优点：与 NTLM 相比，Kerberos 速度更快、更安全，而且同时对服务器和客户端进行身份验证。Kerberos 不是 Windows 专有的身份验证方案，也可以由其它平台实现。很重要的一点在于它允许将标识委派给另一台计算机，因此可以在“服务器至服务器”方案中使用。

结论：推荐在基于 Windows 2000 的 Intranet 解决方案中使用 Kerberos。

有时，需要服务器支持多种身份验证方案（以便允许对多种类型的客户端进行身份验证）。这种情况下，IIS 将发送多个 WWW 身份验证头，详细说明它支持的身份验证方案，客户端将选择它支持的第一个身份验证方案。了解 SoapClient 在特定情况下选择哪种身份验证方案非常重要。请参考表 1，其中描述了 SOAP Toolkit 2.0（更准确的说是 HttpConnector）在各种平台上的行为。

表 1：SOAP Toolkit 2.0 HttpConnector 与 IIS 5.0 的比较

基本 摘要式 Windows 集成 Windows 98 Windows Me Windows NT 4.0 Windows 2000

X X 基本 基本 基本 摘要式

X X NTLM NTLM NTLM Kerberos

X X NTLM NTLM NTLM Kerberos

X X X NTLM NTLM NTLM Kerberos

左边的三列代表服务器提供的身份验证方案。每一行都代表服务器允许的身份验证方案集的一个不同组合。右边的四列显示了可以运行 SOAP Toolkit Client (HttpConnector) 的平台。例如，如果服务器既允许基本身份验证也允许摘要式身份验证，SOAP 将在除 Windows 2000 之外的所有平台上选择基本身份验证。

表 2 显示了 Microsoft SOAP 行为与 IIS 4.0 服务器的比较。

表 2：SOAP Toolkit 2.0 HttpConnector 与 IIS 4.0 的比较

基本 Windows 集成 Windows 98 Windows Me Winodws NT 4.0 Windows 2000

X X NTLM NTLM NTLM NTLM

身份验证支持中的已知局限性：SOAP Toolkit 2.0 使用 NTLM/Kerberos 同时发送域名和帐户名时具有某种局限性。但已经在 SP2 中进行了修正。

代理支持和身份验证

直接访问

默认情况下，SOAP Toolkit HttpConnector 尝试对 Web 服务进行直接调用。如果您不具有 Web 服务的直接访问权限（例如，Web 服务位于您的 Intranet 之外，必须通过代理才能访问），以下脚本将失败：

dim SoapClient

set SoapClient = createobject(“MSSoap.SoapClient”)

SoapClient.mssoapinit(“

“)

Quote = SoapClient.GetQuote()

通过默认代理访问

试图访问 Intranet 之外的网站时，Internet Explorer Web 浏览器将通过在 IE 设置中指定的默认代理服务器。您可以通过 IE/“工具”/“选项”/“连接”/“局域网设置”对话框查看这些设置。若要使 Microsoft SOAP Toolkit (HTTPConnecter) 使用这些设置，应将 UseProxy 属性设置为 TRUE。示例：

dim SoapClient

set SoapClient = createobject(“MSSoap.SoapClient”)

SoapClient.mssoapinit(“

“)

SoapClient.ConnectorProperty(“UseProxy”) = true

Quote = SoapClient.GetQuote()

绕过代理服务器列表。请注意，IE 代理设置中有一个主机列表，您可以连接这些主机来绕过代理服务器。

转至 IE/“工具”/“选项”/“连接”/“局域网设置”对话框。

若要绕过本地服务器，请启用设置“对于本地地址不使用代理服务器”。

若要在连接到其它特定服务器时绕过代理，请单击“高级”按钮。可以在“例外”编辑控件中列出要绕过的服务器，各个服务器名称之间用分号隔开。可以使用通配符“*.soap-company.com”绕过名称中含有 .soap-company.com 的所有服务器。

需要代理服务器来允许绕过本地 Intranet 之外的任何服务器。请注意，用于 HTTP 和用于通过 SSL (HTTPS) 连接的代理服务器不同。代理应允许使用任一协议，以便 SSL 正常工作。

局限性：使用默认代理时，在 Windows 2000 和 Windows NT4 上使用 Microsoft SOAP Toolkit 2.0 HttpConnector 有一个已知问题：它不理解默认 IE 代理设置的“绕过代理”列表。如果选中了“对于本地地址不使用代理服务器”并且在 URL 中指定的主机名不包含“.”，它将绕过代理服务器。但它不理解在 IE 代理设置“高级”菜单中的“例外”文本框中指定的复杂模板。

通过指定代理连接

可以指定哪个代理使用 ProxyServer 和 ProxyPort 连接器属性：

set SoapClient = createobject(“MSSoap.SoapClient”)

SoapClient.mssoapinit(“

“)

SoapClient.ConnectorProperty(“UseProxy”) = true

SoapClient.ConnectorProperty(“ProxyServer”) = “yourproxy”

SoapClient.ConnectorProperty(“ProxyPort”) = 80

Quote = SoapClient.GetQuote()

请注意，如果使用 ProxyServer 属性，则不必将 UseProxy 设置为 True，它将自动设置。

代理身份验证

代理服务器可以在允许连接之前要求您对自身进行身份验证。例如，可以使用它限制在公司 Intranet 内使用 Internet。代理服务器可使用上述所有身份验证方案。Microsoft SOAP Toolkit 2.0 允许您指定代理身份验证的用户名和密码：

set SoapClient = createobject(“MSSoap.SoapClient”)

SoapClient.ConnectorProperty(“UseProxy”) = true

SoapClient.mssoapinit(“

“)

SoapClient.ConnectorProperty(“ProxyServer”) = “secureproxy”

SoapClient.ConnectorProperty(“ProxyPort”) = 80

SoapClient.ConnectorProperty(“ProxyUser”) = “username”

SoapClient.ConnectorProperty(“ProxyPassword”) = “password”

Quote = SoapClient.GetQuote()

如果代理要求 NTLM 身份验证，可以省略用户名和密码，这是将使用当前登录凭据。如果需要指定代理 NTLM 身份验证的域名，请添加“DOMAIN\username”进行服务器身份验证。

局限性。Microsoft SOAP Toolkit 2.0 不支持通过要求身份验证的代理连接到也要求身份验证的服务器。另外，通过要求身份验证的代理的 SSL 连接在 Windows 2000 和 Windows NT4 上不能正常工作。

SSL 和客户端证书

在本节中，我们将具体讨论如何通过安全套接字层 (SSL) 和客户端证书支持进行连接。我们还将讨论 Microsoft SOAP Toolkit 2.0 在使用客户端证书支持的支持平台上的已知局限性。

通常认为 SSL 只是一种加密机制，其实它还提供身份验证。若要使 IIS 4.0/IIS 5.0 支持 SSL 连接，需要获取 X.509 证书，并将其安装在服务器上。

何谓 X.509 证书？

证书是一种结构，其中包含主题、颁发者名称、有效期和其它特征等信息。（有关证书的详细信息，请参阅由 Michael Howard 编著的《设计 Microsoft Windows 2000 基于 Web 的安全应用程序》。） 每个证书都与用于 SSL 加密的一对私有和公用密钥相关。SSL 始终使用 X.509 证书对 Web 服务器进行身份验证。

若要获得证书，需要向证书颁发机构发出证书请求。证书颁发机构 (CA) 是颁发证书的单位。当 CA 向主题（发出请求的实体）颁发证书时，它验证该主题是否与它所声称的相符，并签发新证书和私有密钥。这样，主题可以信任 CA。如果信任颁发证书的 CA，则表示信任向您提供此证书的主题。根目录证书保证 CA 的可信性。多个 CA 可以形成一条信任链：如果信任根 CA，就信任具有根 CA 颁发的证书的中间 CA，因此将信任具有中间 CA 颁发的证书的所有主题。

“信任”的实际意义是什么？可以将 CA 的证书放入“受信任的根目录证书颁发机构”存储区来表示信任该 CA。所有证书都存储在所谓的证书存储区中。有多个默认存储区，例如：

CURRENT_USER\MY\，个人证书存储区，用于当前登录的用户，对其它登录用户不可见

LOCAL_MACHINE\MY\，个人证书存储区，用于所有用户

CURRENT_USER\Root\，受信任的根目录证书颁发机构，包含当前用户信任的根 CA 的证书，如果证书具有到根 CA 证书的证书路径，则当前用户信任该证书的有效性。

LOCAL_MACHINE\Root\，相同，但被所有用户信任

具有被默认信任的根 CA，例如 Verisign。尽管我们的示例将使用一个试用版的 Verisign 证书，但是它们是由不被默认信任的 Verisign 测试机构颁发的。

在服务器上启用 SSL

本节介绍如何创建证书请求、从 Verisign 站点获得试用版的测试服务器端证书，并将其安装在 Web 服务器上。

使用 IIS 4.0 启用服务器上的 SSL

用鼠标右键单击要启用 SSL 的网站，并选择“属性”。

在“目录安全性”选项卡上，单击“编辑安全通信”。

在对话框中，单击“密钥管理器”。

展开树状视图中的“本地计算机”节点。用鼠标右键单击 WWW 叶，并选择“新建密钥”。这将启动称为“密钥管理器”的密钥请求向导。

选择“将请求放入要发送到颁发机构的文件中”和一个文件名。单击“下一步”。

输入一个易记的密钥名称。输入密码，当获取由颁发机构颁发的证书时需要此密码。对于加密密钥字节长度，请选择 1024（1024 为推荐长度，某些颁发机构不颁发小于此长度的证书）。单击“下一步”。

输入您的组织和部门名称。输入等同于完整站点名称的公用名称，例如

。在启动 SSL 连接之前，客户端将检查站点名称是否与证书的公用名称相同。单击“下一步”。

输入国家（地区）、省/自治区、市/县所在地。证书颁发机构可能检查这些信息是否一致，以确保输入的信息有效。输入省时，请输入完整的省名称。

输入管理服务器的人员的姓名、电子邮件地址和电话号码。这些信息不包含在证书中，但证书颁发机构需要这些信息。

包含您的请求的文件已经创建。该文件为 Base64 编码格式。在此过程中，IIS 还将为该证书请求创建一个私有密钥和一个公用密钥。私有密钥将保存在您的计算机上，而公用密钥将随请求一起发往 Verisign，并用以加密证书数据。

转至

（英文），并单击“Get Trial SSL ID”。注册证书时，会要求您提供 CSR（证书签名请求）。复制并粘贴您的请求文件中自行“BEGIN NEW CERTIFICATE REQUEST;”之后的内容，否则，将会出错。Verisign 以邮件形式将测试服务器端证书发送给您。该过程同样适用于商业证书，不同之处在于它收费并仔细验证提交的信息。

确保从证书颁发机构获得的证书是 Base64 编码的。如果证书颁发机构是 Verisign，则您可以通过电子邮件获得证书。创建一个扩展名为 .cer 的空文件，复制行“BEGIN CERTIFICATE”和“END CERTIFICATE”之间（包含这两行）的所有内容并粘贴到该文件。

转至要启用 SSL 的站点的“属性”/“目录安全性”选项卡。单击“编辑安全通信”，然后单击“密钥管理器”。

在对话框中，展开树状视图中的“本地计算机”节点，再展开 WWW 叶，将显示您的证书请求的密钥。由于该证书尚未安装，它标记为红色。用鼠标右键单击该证书，并选择“安装密钥证书”。选择具有要安装的证书的文件。将提示您提供以前设置的密码。输入密码。现在，您的证书已安装。

使用 IIS 5.0 启用服务器上的 SSL

用鼠标右键单击要启用 SSL 的网站，并选择“属性”。

在“目录安全性”选项卡上，单击“编辑安全通信”。

单击“服务器证书”打开服务器证书向导。该向导将记忆网站的当前状态，例如您是否已拥有服务器证书。（现在假设您没有证书。）

在证书向导中，单击“下一步”，选择“创建一个新证书”，然后单击“下一步”。

选择“现在准备请求，但稍后发送”，并单击“下一步”。

输入证书的友好名称。该名称不会在证书结构中使用，但作为区分请求和证书的一种方法。选择公用密钥长度。推荐密钥长度不小于 1024 字节。单击“下一步”。

输入可以由颁发机构验证的组织名称和部门名称，如果您请求用于商业目的的真实证书，请输入有效名称。输入要被认证的计算机的名称。注意：它必须等同于您的完整站点名称，例如

。单击“下一步”。

输入国家（地区）、省/自治区、市/县所在地。请输入有效信息，证书颁发机构将检查这些信息是否一致。输入省时，请输入完整的省名称。单击“下一步”。

输入用于保存请求的请求文件名称。单击“下一步”。

将摘要显示您输入的内容。确认内容正确，并单击“下一步”完成向导。包含请求的文件将以 Base 64 格式保存。

包含您的请求的文件已经创建。该文件为 Base64 编码格式。在此过程中，IIS 还将为该证书请求创建一个私有密钥和一个公用密钥。私有密钥将保存在您的计算机上，而公用密钥将随请求一起发往 Verisign，并用以加密证书数据。

转至

（英文），并单击“Get Trial SSL ID”。注册证书时，会要求您提供 CSR（证书签名请求）。复制并粘贴您的请求文件中自行“BEGIN NEW CERTIFICATE REQUEST;”之后的内容，否则，将会出错。Verisign 以邮件形式将测试服务器端证书发送给您。该过程同样适用于商业证书，不同之处在于它收费并仔细验证提交的信息。

确保从证书颁发机构获得的证书是 Base64 编码的。如果证?/ca>

参考资料：

原文链接：https://www.cnblogs.com/raylynn/archive/2007/10/13/923135.html