好了！
我绝对喜欢让我们加密，但这是我在这里的第一篇文章，尽管我读了一页又一页，但我不是证书和SSL方面的专家，我发现关于我的实际用例的信息很少。我已经在我的公司网站和文件共享系统上使用了让我们加密，并且已经设置好了，没有任何问题。
然而，这个问题是围绕我的职业展开的：我安装了楼宇管理系统，它提供了一个选项，可以合并HTTPS和其他加密协议来增强安全性。虽然大多数安装者不会为此而烦恼，因为他们觉得这很难而且没有必要，但我显然会这样做，因为我在这里发帖。
加密通过自生成、自签名的证书工作，因此尽管它们极大地增强了安全性，但它们对用户不是很友好，因为用户会收到关于不受信任的证书(应用程序在Java上运行)的(许多)警告。
一些安装将托管在客户端站点，或者直接托管在控制器中，或者托管在现场服务器中。其他的将由我在数据中心使用VPS进行托管。每台设备(服务器、控制器、虚拟电源、…)会有自己的证书，这些证书是由我自己的根证书或中间证书签名的。
我在想的是，如果我可以使用我们的加密来签署我的根证书(作为运行在我的托管服务器上的服务)，从而实现我的所有证书(即使是在控制器级别)都被浏览器信任，但显然不像CA那样进行验证？
我还没有检查，在许可协议中是否真的允许使用这种用例，但如果是这样的话-在技术上是可行的吗？如果是这样的话，我将如何着手设置它，在大纲中？
好心的，
尼古拉，由奥西里斯在9号帖子中解决
如果HTTPS连接实际上是在服务器端终止的(即，不是像NAT等那样被转发到您的网络中)，则用户仅处理到您的“服务器”的HTTPS连接。从用户的角度来看，服务器为向用户提供内容所做的一切都是无关紧要的。
所以你可以用…、Nicolise：
我在想的是，如果我可以使用我们的加密来签署我的根证书(作为运行在我的托管服务器上的服务)，从而实现我的所有证书(即使是在控制器级别)都被浏览器信任，但显然不像CA那样进行验证？
让我们只加密签名结束叶证书。也就是说，信任链到此为止。您不能使用让我们再次加密证书来为以后的东西签名。
此外，核实和信任是齐头并进的。如果浏览器无法向受信任的CA验证证书，您如何期望浏览器信任该证书？，[QUOTE=“Osiris，POST：2，TOPIC：29719”]
让我们只加密签名结束叶证书。也就是说，信任链到此为止。您不能使用让我们再次加密证书来签署以后的东西。[/QUOTE]
谢谢，这回答了我的问题。不过，这显然不是我所希望的答案。但我显然忽略了一些事情，因为这是物联网等非常常见的场景。我只希望我知道是什么。
奥西里斯：
此外，核实和信任是齐头并进的。如果浏览器无法向受信任的CA验证证书，您如何期望浏览器信任该证书？
这可能是一个糟糕的措辞。我指的是证书持有者的验证，即域名验证、组织验证和扩展验证。让我们加密是一个域验证，这在某种程度上是可行的，但除了您对DNSA记录和所述记录的目标的控制之外，并不能真正验证太多。
我的意思是，我显然不能在建筑控制系统上使用扩展验证或组织验证，因为这需要每个站点都有一个单独的CA签名。但像We‘s Encrypt这样的域验证将是现实的。
这可能是一个糟糕的措辞。我指的是证书持有者的验证，即域名验证、组织验证和扩展验证。让我们加密是一个域验证，这在某种程度上是可行的，但除了您对DNSA记录和所述记录的目标的控制之外，并不能真正验证太多。
啊……那么，如果您想要公共认可的证书，即使您会找到某个CA为您颁发具有末端叶证书签名功能的证书，您也需要遵守CAB论坛的基准要求。因此，不能在不验证主机名的情况下就去颁发证书。
如果您需要颁发不符合基线要求的证书，唯一的选择将是设置您自己的CA。但是，除非您将根证书安装到浏览器/系统中，否则这些证书在浏览器中是不可信的。只有在您能够控制客户端的情况下，这才是一个可行的选择。，[QUOTE=“Osiris，POST：4，TOPIC：29719”]
啊……那么，如果您想要公共认可的证书，即使您会找到某个CA为您颁发具有末端叶证书签名功能的证书，您也需要遵守CAB论坛的基准要求。因此，不能在不验证主机名的情况下就去颁发证书。
这很有意义，尽管看起来很简单，但实际上我并没有考虑到省略主机验证的明显问题。
奥西里斯：
如果您需要颁发不符合基线要求的证书，唯一的选择将是设置您自己的CA。但是，除非您将根证书安装到浏览器/系统中，否则这些证书在浏览器中是不可信的。只有在你能控制客户的情况下，这才是一个可行的选择。
这就是它目前的工作方式-我将每个证书添加到其他控制器的信任存储中，并添加一个安全额外选项以在客户端计算机的浏览器中接受我的证书。大多数情况下，这些系统是从相当少的端点(通常不超过3个)访问的，但这种趋势发生了变化。
不过，我绝对不需要更多的客户管理。当前的解决方案通过浏览器插件在Java上运行，现在才转向WebStart Java。出于这个原因，我正在转向HTML5解决方案。
我不禁觉得，这个问题应该有一个解决方案，我只是忽略了这一点。以Nest这样的例子为例--你可以在本地(显然)访问恒温器，也可以通过和应用程序和网站远程访问。我非常希望并假设通信是加密的，不仅是用户到网站，也是网站到设备。
出于同样的原因，我已经联系了制造商和供应商，因为我觉得他们处于一个理想的位置来处理这个问题，因为他们基本上可以验证我的身份，可以验证产品身份和预期的安装地点，只需要在安装后做一个域验证。但他们不想实施主机名验证过程，也不愿意承担维护一个CA签名的根证书的费用。
然而，这种用例在世界各地都存在，有无数的实现。因此，肯定有一些方法可以在不控制客户端环境的情况下解决这个问题，也不会四处发出警告，但遗憾的是，我不知道这个解决方案会是什么。
我不禁觉得，这个问题应该有一个解决方案，我只是忽略了这一点。以Nest这样的例子为例--你可以在本地(显然)访问恒温器，也可以通过和应用程序和网站远程访问。我非常希望并假设通信是加密的，不仅是用户到网站，也是网站到设备。
Nest显然控制着客户：他们自己制造Nest设备，包括固件。因此，他们可以很容易地将Nest Private Root证书颁发机构的根证书包含到Nest产品中。
(Nest使用一个称为私有服务器证书颁发机构的中间证书，该证书由带有*.devices.nest.com的末尾叶证书的有孔根证书签署)
但出于某种原因，我怀疑你的情况不像Nest那么简单……有一篇关于Plex如何为类似用例实现HTTPS的很好的博客文章，可能会提供一些启发。Acme-DNS可能是使用We‘s Encrypt的类似解决方案的一个很好的构建块。
但出于某种原因，我怀疑你的情况不像Nest那么简单。
这取决于HTTPS中是否有某种机制(我假设有)，以保护用户免受具有可信HTTPS连接的服务器的攻击，该服务器显示来自另一个HTTPS连接但来自不可信来源的内容？所以不是典型的“HTTPS内的HTTPS内容”警告，而是“来自其他地方的HTTPS”。
如下所示：
用户=HTTPS(签名)=>我的服务器*=HTTPS(未签名)=>控制单元
*)托管证书的服务器使用让我们为访问者连接加密，同时还将我的控制单元的证书添加到它的受信任证书中。
我想知道这是否可能在不警告用户的情况下实现？如果它被认为是一个好的解决方案，那就是长期稳定的--也就是说，不会利用一些简单地等待修复的明显错误。
PFG：
有一篇关于Plex如何为类似用例实现HTTPS的很好的博客文章，可能会提供一些灵感。Acme-dns可能是使用We‘s Encrypt的类似解决方案的一个很好的构建块。
谢谢!这真的很有用。
我认为就目前的问题而言，这有点过头了，因为我不太可能让CA为我开发类似的东西，因为我的实现(与Plex相比)要小得多。但特别是对于我正在为同一市场开发的另一个项目来说，dydns技巧非常有用，在这个项目中，我可能无论如何都需要一台小型计算机(即PI或Arduino)出现在控制柜中。(我没有访问控制器的固件，只能输入一种脚本语言，并且只能使用批准的功能)。到时候我一定会记住Plex的实现，所以非常感谢你！
*)托管证书的服务器使用让我们为访问者连接加密，同时还将我的控制单元的证书添加到它的受信任证书中。
我想知道这是否可能在不警告用户的情况下实现？如果它被认为是一个好的解决方案，那就是长期稳定的--也就是说，不会利用一些简单地等待修复的明显错误。
如果HTTPS连接实际上是在服务器端终止的(即，不是像NAT等那样被转发到您的网络中)，则用户仅处理到您的“服务器”的HTTPS连接。从用户的角度来看，服务器为向用户提供内容所做的一切都是无关紧要的。
这样你就可以建立你自己的“私人”CA了。您可以将根证书放入“中央”服务器的信任存储中，并为控制单元使用末端叶证书(出于安全原因，可能使用中间证书)。
如果HTTPS连接实际上是在服务器端终止的(即，不是像NAT等那样被转发到您的网络中)，则用户仅处理到您的“服务器”的HTTPS连接。从用户的角度来看，服务器为向用户提供内容所做的一切都是无关紧要的。
太棒了。此服务器不会转发流量，出于安全原因，我有一个单独的VPS用于服务和监控(VPN和监管工具)。为了提供冗余和安全性，将不会授予客户端通过此服务器的任何访问权限。
那么它应该会起作用，因为可视化软件通过它的幕后框架，使用DSA等传输协议订阅控制器中的数据点。当数据点实际显示给用户时，这是通过使用HTML5和CSS进行布局和格式化来实现的，并且源(数据点值)基本上被发送到浏览器，就像任何其他文本元素一样。如果它是一个图形表示，它将简单地根据值选择正确的图像(例如风扇运行或停止)，同样在幕后，并简单地将结果输出到浏览器-很像PHP脚本的工作方式。
根据您的解释，这个概念那时会起作用，我唯一的不满是那些选择自托管/现场服务器的客户，其中证书将保持未签名。我认为可以公平地说，如果客户端维护服务器，那么如果他们愿意的话，他们也有责任提供自己的证书。无论如何，我制作的自签名证书将启用加密并允许未经验证的身份识别。
奥西里斯：
因此，您确实可以设置自己的“私人”CA。您需要将根证书放入“中央”服务器的信任存储中，并为控制单元使用秋叶证书（出于安全原因可能使用中间证书）。
这绝对是要走的路。我已将您最新的这篇帖子标记为解决方案，而不是上一篇，因为它准确地回答了我第一次想问的问题。 非常非常感谢。我真的很感激！
