当这些服务器通过我们的测试时，我的客户网站会根据每个IP为其客户提供证书。此认证仅适用于已测试的IP。因此，我们需要成为提供证书的人，以便我们可以验证显示我们证书的网站是否确实由我们测试。因此，当客户的用户点击证书的链接时，他们可以相信该网站确实已经过我们的测试（该网站没有被我们未经过测试的其他服务器提供服务，但声称是
用户通过以下链接指向我们的网站：
siteB.com/certificate.php?companyid=1234&serverid=4321
简化了流程：
最初，我认为$ _SERVER var可能有一个值来指示引用服务器是谁，但我收到的关于该问题的答案表明虽然该信息存储在$ _SERVER [“HTTP_REFERER”]中，它不可靠（插件或用户可能会修改此值）。
由于我不能依赖它，我需要另一种方法来验证引用服务器是否是他们声称的人。我考虑使用一次性使用令牌，但是有效的服务器可以简单地将令牌传送到客户拥有的其他服务器（尚未经过测试），并且客户可以通过这种方式声称他们的任何数量的服务器都经过认证由我们仅为一次测试的价格（以及损害证书的完整性）。
我想知道这个问题是否不可能成为一个万无一失的解决方案，并且可以做的最好的事情是混淆不受控制的端点（客户的服务器）意味着发布密钥以表明它们是一个证书是为了（例如，一个偷偷摸摸的客户将不得不阅读一些混乱的混淆javascript，或反汇编闭源客户端程序，以欺骗系统）。
到目前为止我的想法是这个（而且很可怕）：
我需要制作一个闭源程序来运行客户端，可能是通过点击客户网站（站点A）上的证书链接启动的Native Client，这将首先验证自己使用我的站点（站点B），然后打开与站点A的服务器，站点B的服务器和用户的3路通信线路，其中站点B将验证站点A是否是他们所说的人，然后返回到用户要么是证书，要么是错误消息，说明无法加载证书的原因（例如连接超时）。
站点B上的脚本以及用户NaCl程序的开放流将use curl获取站点A的服务器的IP地址并进行验证。
对我来说，这是一个非常粗糙的解决方案（如果它甚至是一个解决方案），虽然大多数用户不会关心某人的证书，但让关心的用户通过箍（安装和运行NaCl）程序）只是看证书只是疯狂。
这感觉有点像一个愚蠢的问题，但是将其作为闪存运行而不是像运行NaCl程序一样安全/不安全？
当然，有更好的方法可以做到这一切......
答案 0 :(得分：2)
您最好的选择是信任REFERER或使用ORIGIN标头（您需要设置一个AJAX脚本，可以将其放入站点以使用ORIGIN）。
您的服务器收到的任何内容都很容易被客户端计算机欺骗，但不会被他们正在访问的服务器欺骗（未经客户同意）。由于您的服务似乎是针对客户端的，因此他们没有理由伪造凭据。您可能会遇到某些插件和代理的潜在问题，但您的警告信息可以解释这一点。
没有闭源客户端代码这样的东西。任何人都可以简单地对其进行反编译或模拟运行时，因此您将无法获得额外的安全性。
公钥/私钥也不起作用（您的站点生成要编码的东西，有问题的服务器必须使用其私钥对其进行编码，客户端使用公钥进行检查）。他们仍然容易受到同样的问题：虚假网站可以将请求以及完美复制的标题转发到真实网站进行处理。
要记住的事情：
答案 1 :(得分：1)
我的想法......如果可能的话，让证书颁发服务器根据引用服务器的名称创建一个hash的cookie，并根据另一组标准创建一个salt的cookie。动态但可预测的方式，例如使用用户的IP地址加上星期几，并且可能会抛出小时或当前分钟的数量（标准上的时间太短会导致某些误报认证失败，所以要小心）。然后，当用户到达您的站点时，读取cookie的哈希值并将其与$_SERVER[“HTTP_REFERER”]生成的哈希值和预先建立的标准进行比较。这样做的缺点是引用服务器可以发布安全算法，如果他们想成为dicks。
另一个可能更安全的选项是创建一个JavaScript应用程序，您可以将该服务器提供给发送服务器AJAX调用的引用服务器，然后您的服务器根据我上面提到的相同类型的条件返回一个哈希值。然后，引荐服务器会根据您的AJAX返回的哈希值设置Cookie，当它们到达您的网站时，会按照我之前提到的方式进行检查。但由于所有处理都在您的服务器上进行，因此它非常安全。听起来很酷的项目，祝你好运。