2016-04-13 47 views
0

一个微软的Azure云服务具有在服务定义中定义这样一个Web角色:SSL证书验证有时成功,有时失败

<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连接时开始报告一些模糊的问题。

Safari浏览器在iOS上报道说这是无法验证服务器的身份,卷曲报道说这是无法得到如thisthis报道说当地的颁发者证书和第三方SSL验证工具证书安装不正确。

该问题未得到一致的转载。有时候请求会成功,有时会失败。第三方工具有时会报告服务已正确配置,有时会报告其配置错误。

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

什么可能导致此问题?

回答

1

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

<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只提供服务证书。

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

您的服务定义的底线会导致不可靠的服务行为。根据列出中间体证书元素来解决这个问题。

+0

你能在你的答案中包含更新的Azure文档链接吗? –

+0

@GauravMantri完成。 – sharptooth

相关问题