【问题标题】:SSL certificate validation sometimes succeeds and sometimes fails when clients connect to an Azure Cloud Service当客户端连接到 Azure 云服务时,SSL 证书验证有时会成功有时会失败
【发布时间】:2016-08-04 08:51:33
【问题描述】:

Microsoft Azure 云服务有一个 Web 角色,在服务定义中定义如下:

<ServiceDefinition name="Magic" schemaVersion="" xmlns="[WHATEVER]">
   <WebRole name="MagicRole">
      <Sites>
        <Site name="Web" >
          <Bindings>
            <Binding name="HttpIn" endpointName="HttpIn" />
            <Binding name="HttpsIn" endpointName="HttpsIn" />
          </Bindings>
        </Site>
      </Sites>
      <Endpoints>
        <InputEndpoint name="HttpIn" protocol="http" port="80" />
        <InputEndpoint name="HttpsIn" protocol="https"
           port="443" certificate="ServiceCert"/>
      </Endpoints>
      <Certificates>
        <Certificate name="ServiceCert"
           storeLocation="LocalMachine" storeName="My" />
      </Certificates>
   </WebRole>
</ServiceDefinition>

该服务几个月来一直运行良好。最近,用户在建立与服务的 SSL 连接时开始报告一些晦涩难懂的问题。

iOS 上的 Safari 报告说它无法验证服务器身份,cURL 报告说它无法获得本地颁发者证书和第三方 SSL 验证工具,例如据报道thisthis 表示证书安装不正确。

问题没有被一致地重现。有时请求会成功,有时会失败。第三方工具有时会报告服务配置正确,有时会报告其配置错误。

在用户开始报告这些问题之前的两周内,服务中没有任何变化。

什么可能导致这个问题?

【问题讨论】:

    标签: azure ssl iis curl azure-web-roles


    【解决方案1】:

    您的服务定义已损坏。 Azure documentation 最近已更新以显示正确的配置。 Certificates 元素必须列出服务证书信任链中的所有中间证书。中间证书不会绑定到任何端点,它们只需要被列出。方法如下:

    <Certificates>
      <Certificate name="IntermediateCAForServiceCert"
           storeLocation="LocalMachine" storeName="CA" />
      <!-- List all intermediate certificates from the chain
         when the chain contains more than one intermediate-->
      <Certificate name="ServiceCert"
           storeLocation="LocalMachine" storeName="My" />
    </Certificates>
    

    通过这样的配置,中间证书被安装到本地存储中,IIS 可以在那里找到它并提供给客户端(连同服务证书),以便客户端可以验证服务证书链。

    在您的配置中,您可能会看到“它可以工作”,因为在 Windows/IIS 深处的某个地方存在未记录的行为。这个answer 显示了证明。简而言之,当服务证书被安装到角色实例中时,中间件中的某些东西会尝试从 CA 基础结构中获取丢失的中间证书并将它们存储在本地某处(而不是证书存储中)。如果获取成功,则 IIS 拥有证书并可以将其提供给客户端。如果获取失败(网络问题、CA 基础设施暂时不可用等),则 IIS 仅提供服务证书。

    请记住,您的网络角色前面有一个负载平衡器。不同的请求可能会到达不同的实例。如果您的服务横向扩展并且启动了新实例,它们可能无法获取中间体,并且到达它们的请求将产生没有中间体的响应,这会使用户不满意。某些实例可能被重新定位或重新映像,并且无法重新获取中间体,这将导致相同的问题。

    您的服务定义导致不可靠的服务行为的底线。在 Certificates 元素下列出中间体来解决这个问题。

    【讨论】:

    • 您能否在答案中包含更新 Azure 文档的链接?
    猜你喜欢
    • 2016-06-04
    • 1970-01-01
    • 2015-03-22
    • 1970-01-01
    • 2011-11-21
    • 2014-05-31
    • 1970-01-01
    • 2014-10-28
    • 1970-01-01
    相关资源
    最近更新 更多