嵌套在非安全页面上的安全 IFRAME

发布于 2024-12-03 13:06:41 字数 1077 浏览 0 评论 0原文

我有一个客户端,由于特定原因,需要在 HTTP 页面上放置一个指向 HTTPS 页面的 IFRAME 。 HTTP 页面托管在与 HTTPS 页面不同的域和服务器上,但均属于同一客户端。

抛开为什么不应该这样做的原因不谈,我发现在实践中很难实施。

正如在此页面上看到的:http://www.clevelandutilities.com/obppay.htm HTTP 页面上有一个 HTTPS IFRAME,浏览器(Firefox 或 IE)不会发出任何警告。但是,如果我尝试相同的方法,Firefox 和 IE 都会抱怨该证书。

关于为什么会这样的任何想法吗?我检查了该示例站点的源代码,看不出有什么特别的事情发生,但如果我尝试同样的事情,我就会尖叫。此外,如果我输入他们正在使用的域名 (https://www.paybill.com/cu/),它不会抱怨 - 如果我把我们的域名放在它上面,它就会抱怨。 创建的所有 SSL 证书都是平等的吗?

归根结底,这可以在没有警告的情况下工作:

<iframe src="https://www.paybill.com/cu/" width="100%" height="600" scrolling="auto"></iframe>  

这不是:

<iframe src="https://www.myclientdomain.com/somepage.php" width="100%" height="600" scrolling="auto"></iframe>

此外,我们使用 IFRAME 样式的 Facebook 应用程序通过管道连接到此相同的 HTTPS 页面,并且无需担心 SSL 证书的问题。啊?!

I have a client that, due to specific reasons, needs to place an IFRAME pointing to an HTTPS page on an HTTP page. The HTTP page is hosted on a different domain and server than the HTTPS page, but are both owned by the same client.

Putting aside the reasons why this should not be done, I am finding it difficult to implement in practice.

As one can see on this page: http://www.clevelandutilities.com/obppay.htm there is a HTTPS IFRAME on an HTTP page without any warnings from the browser (Firefox OR IE). However, if I try the same method, both Firefox and IE complain about the certificate.

Any ideas on why that is? I've examined the source at that sample site and can see nothing special being done, yet if I try the same thing I get squawking. Further, if I put the domain that they are using (https://www.paybill.com/cu/), it doesn't complain - if I put our domain it, it complains. Are all SSL certificates created equal?

To boil it down, this works without warnings:

<iframe src="https://www.paybill.com/cu/" width="100%" height="600" scrolling="auto"></iframe>  

this does not:

<iframe src="https://www.myclientdomain.com/somepage.php" width="100%" height="600" scrolling="auto"></iframe>

Further, we use an IFRAME-style Facebook app to pipe in to this same HTTPS page, and THAT works with no complaints about the SSL certificate. Huh?!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

眼泪淡了忧伤 2024-12-10 13:06:41

经过一番挖掘,我们发现该证书特定于 www.myclientdomain.com,并且负责的开发人员使用了 ...src="https://myclientdomain.com" ...IFRAME 中。这导致出现以下“连接不受信任”错误屏幕:

不受信任的错误屏幕截图

主机域的常见做法是永远不要在 URL 中使用“www”(通过 .htaccess 强制执行),而源域(带有证书的域)的标准是始终使用它(通过 .htaccess 强制执行)。这就是导致其他开发人员放弃它的原因 - 这就是他的网站所习惯的。

如果对源域单击“我了解风险”(即使一次)并添加证书例外,则此后的任何访问都会访问 htaccess 并重定向到 www-,这就是为什么在我(和其他开发人员)计算机上的原因当我们的老板收到警告时,页面可以正常加载并在 Firebug 中检查正常。过去我们(显然)都因为这样或那样的原因添加了例外。

当我们把它们放在一起时,那是一个真正的捂脸时刻。感谢任何思考过这个问题的人,很抱歉没有足够仔细地检查细节。 :)

After digging a bit, we uncovered that the certificate is specific to www.myclientdomain.com, and the developer in charge had used ...src="https://myclientdomain.com"... in the IFRAME. This was causing the following "Connection is untrusted" error screen:

Untrusted error screenshot

The common practice for the host domain is to never use 'www' in the URL (enforced with .htaccess), whereas the standard for the source domain (the one with the certificate) is to always use it (enforced with .htaccess). That's what lead the other developer to leave it off - that's what he is used to for his site.

If one clicked "I understand the risks" even once for the source domain and added the certificate exception, any visit thereafter would have made it to the htaccess and be redirected to www-, which is why on my (and the other developer's) computer the page would load fine and check out normal in Firebug while our boss got the warning. We had both (apparently) added the exception for one reason or another in the past.

When we put it together, it was a real facepalm moment. Thanks to anyone who had given this question thought, sorry to have not checked the details carefully enough. :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文