iPhone 上的 SSL 问题
我已将 SSL 证书（来自 godaddy，但也尝试过 Rapidssl）添加到网站。
Safari 和 IE 都可以浏览到 https:// 并报告证书有效，且不会出现警告。但是，如果我尝试从 iPhone 浏览到同一地址，则会收到无效证书错误。我使用 heroku 作为相关网站的主机。
有人见过这个吗？我很困惑为什么 2 部不同的 iphone 无法做到这一点，但桌面浏览器就很好......
I've added an SSL certificate (from godaddy, but also tried rapidssl) to a website.
Safari, and IE can both browse to https:// and report that the certificate is valid, with no warnings. If, however, I try to browse to the same address from an iPhone I get an invalid certificate error. I'm using heroku as a host for the website in question.
Has anybody seen this? I'm stumped why 2 different iphones would fail to do this, but desktop browsers are just fine...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这里的问题是 iPhone 不支持服务器名称指示 (SNI)，而这是让 Heroku 的 SNI SSL 正常工作所必需的。 （编辑）iOS 3.2 及以上版本现在支持它。
您可以通过手机上的 Safari 访问以下 URL 来确认 SNI：
https://sni.velox.ch
我发现我可以在 iphone 客户端中设置以下 SSL 设置：
kCFStreamSSLPeerName = Null
...这解决了问题。但我还没有弄清楚这如何影响安全性 - 文档不是很清楚。
据我了解，当您在 Heroku 等云主机上设置自定义域时，它会指向代理，并且该名称与您的证书主机名不匹配。 Safari 和 IE 等浏览器支持 SNI，并且知道如何解决这一问题 - 但手机不支持。
正如我上面所说，现在这不再是一个问题，除非您支持 iOS 3.1.3 或更低版本...
The problem here turned out to be that the iPhone does not support Server Name Indication (SNI), which is required to make SNI SSL from heroku to work. (EDIT) It is now supported on iOS 3.2 onwards.
You can confirm SNI by going to the following URL from Safari on the phone:
https://sni.velox.ch
I figured out I can set the following SSL setting in the iphone client:
kCFStreamSSLPeerName = Null
... and this fixes the problem. But I haven't figured out yet how this affects security - the docs aren't very clear.
As far as I understand this, when you setup a custom domain on a cloud host such as heroku, it points to a proxy, and that name doesn't match your certificate host name. Browsers such as Safari and IE support SNI, and know how to figure this out - but the phone doesn't.
As I said above, this is less of an issue now, unless you are supporting iOS 3.1.3 or less...
您还需要引用中间证书，以便将整个证书链返回到根证书。
请参阅此博文 了解相同问题的描述以及他如何为 Apache 解决该问题。
You also need to reference the intermediate certificate so that you have the entire certificate chain back to the root certificate.
See this blog post for a description of the same problem and how he solved it for Apache.
仅仅是因为这两个证书颁发机构不在 iPhone 的受信任证书存储中，但它们适用于 Windows、Firefox 等。
编辑：
我猜前面的海报是正确的，您没有捆绑中间证书。您的证书可能已由rapidssl.com 签名，但rapidssl.com 的证书是由Equifax 签名的。每个证书都有一个颁发者名称字段和一个主题名称字段；将它们视为一对名称 (X,Y)。您的证书的主题名称反映了您的网站名称，并且由rapidssl 签名，因此该对类似于（rapidssl，www.whatever.com）。 Rapidssl 证书由Equifax 签署，因此这将成为一对（Equifax、rapidssl）。并且Equifax证书可能有（Equifax，Equifax）。根证书应具有相同的颁发者和主题名称。正如您所看到的，这形成了一条 (A,A) (A,B) (B,C) (C,D) .... 形式的链，无论它持续多久。它很少超过 3。SSL 的规则是您应该发送链中的每个证书，除了根证书。有些客户可能已经拥有中间证书，但您永远不应该指望它。
Simply because those two certificate authorities are not in the trusted certificate store of the iPhone, but they are for Windows, firefox, etc.
EDIT:
I'm guessing the previous poster is correct, you are not bundling the intermediate certs. You certificate might have been signed by rapidssl.com, but rapidssl.com's certificate was signed by Equifax. Every certificate has an Issuer Name field and a Subject Name field; think of these as a pair of names (X,Y). Your certificate's subject name reflects your website name, and it was signed by rapidssl, so that pair is something like (rapidssl, www.whatever.com). The rapidssl cert was signed by equifax, so that would make the pair (equifax, rapidssl). And the equifax cert might have (equifax, equifax). The root cert should have the same issuer and subject name. As you can see, this forms a chain of the form (A,A) (A,B) (B,C) (C,D) .... for however long it goes. It is rarely longer than 3. The rule for SSL is that you should send every certificate in the chain except the root certificate. Some clients may already have the intermediate cert(s), but you should never count on that.
我知道这个问题已经得到解答，但为了以防万一有人再次遇到这个问题，我想我会分享我错过的东西，因为我最近刚刚经历了同样的头痛，但架构略有不同。
我们的服务器设置有点不同，因为我们有 stunnel 解密 ssl 流量，将其传递到 haproxy，后者将其路由到 apache，后者将其代理到我们的应用程序服务器。在与 apache 搞乱了一段时间后，我意识到 stunnel 配置不包含中间证书，因此我连接了域证书（首先），然后连接了中间证书（以形成一个大的长证书链）。
这解决了我的问题。
I know this has been answered, but just in case anyone comes across this problem again I thought I'd share what I missed since I just recently went through the same headache but have a slightly different architecture.
Our server setup was a little different in that we had stunnel decrypting ssl traffic, passing it on to haproxy which would route it to apache which would proxy it to our application servers. After messing with apache for a while I realized that the stunnel config did not include the intermediate certificates so I concatenated the domain certificate (first) and then the intermediate certificates (to make one big long chain of certificates).
That fixed the problem for me.