工业物联网是对工业设施，建筑物，商业设施的工程系统进行监视，调度和自动化。 各种参数的传感器，仪表和控制器从这些对象收集数据，例如服务器机房中的温度和湿度，公寓楼中水表的读数，机房中的二氧化碳水平。 控制器处理此信息，并将所有内容发送到“云”。
Wiren Board生产用于工业物联网的Linux控制器。 设备从油井和银行分支收集数据，监视服务器和超级市场中的小气候。 控制器与公司合作伙伴的顶级系统集成。 系统对设备进行身份验证-他们了解自己正在与自己的传感器（而不是与他人的传感器）通信，然后进行授权。 在这个阶段出现了一个问题-有成千上万的控制器，成百上千的客户，但是没有单一的集成系统。 简单的传统方法（例如登录名/密码对）容易受到攻击，并且部署不便。
因此，该公司在使用硬件密钥的顶级系统中开发了身份验证-基于标准的非对称加密技术，使用硬件保护的元素来存储密钥。 现在，不需要统一的集成系统-保护了身份验证和授权，并且可以立即使用。
Evgeny Boger将告诉您如何执行此操作：他们如何选择“加密芯片”，如何将其固定在硬件和Linux上，如何使通用库和软件与它成为朋友。 特别强调部署：在生产中引入设备初始化，引入对各种顶级软件的支持，包括在别人的和封闭的软件中。
关于发言人： Eugene Boger （
evgeny_boger ）-Wiren Board的首席技术官兼联合创始人。 从事嵌入式系统，尤其是嵌入式Linux。
问题所在
首先，我们正在做什么，这个问题是从哪里来的。 我们在俄罗斯的Wiren Board设计和制造设备。 它曾经被称为M2M，但现在是工业物联网。 这是建筑工程系统的自动化，监视和调度。 简而言之，所有工作都是这样的：各种参数的传感器，执行器，计数器和控制器（边缘计算或IoT网关）从对象中收集不同的数据，对其进行处理，执行本地逻辑，然后将它们收集到一个大型的调度，监视或控制系统中。
与某些竞争者不同，我们没有一个完整的生态系统。 我们生产与合作伙伴的多个顶级系统集成的设备。 有很多合作伙伴公司，他们共同承担责任。 没有良好的技术手段，整合将无法进行-只是无法谈判。
有两种简单的解决方案可以解决这些问题。 第一个是像每个人一样
将用户名/密码提供给客户端 ，第二个是
在工作场所中生成并缝制“秘密” 。 两种选择都不适合我们-我会告诉你原因。
简单的解决方案
第一种解决方案是向客户端发出用户名和密码 。 直到最近，我们所有人都这样做。
要验证将数据发送到某个系统的设备的身份，您可以创建一个秘密密钥-有条件的登录名/密码（“秘密”）。 这在控制器和从多个控制器收集数据的顶级系统上很常见。
必须以某种方式将几个用户名/密码（一个常见的“秘密”）提供给客户-公司或个人。 必须有人生成一个秘密对，通过电子邮件发送，通过帐号对客户端进行身份验证。 这是标准程序-低技术。
问题 。 就是我们有很多这样的系统。 我们的客户，他可以将数据发送到我们合作伙伴的系统。 这是所有参与方之间的复杂交互。
除了许多系统的问题外，还有其他问题。
- 交货不良并交付给客户 。
- 登录名和密码存储在服务器上 。 如果我们还存储散列，这将使我们免受泄漏的影响。 但是即使如此，当所有客户端控制器的密钥存储在服务器上时，仍然会出现令人不快的感觉。 其中一些可以处理关键任务：室外照明，监控石油钻机。
- 服务之间的同步 。
- 损失追回 。 当客户端擦除控制器的内存时，不清楚丢失时该怎么办-我应该在哪个内存中写入？ 您必须再次重复一遍。
- 防止复制详细信息 。 有付费的监视系统，可为客户提供服务并收取订阅费。 我不希望最终客户能够通过我们以某种方式绕过系统-支付一次，但使用两次。
第二种解决方案是在生产中生成并缝合“秘密” 。 这是对先前解决方案的改进。
方案是这样的：作为控制器的制造商，我们为每个人预先生成了用户名和密码，将它们缝入我们的系统并输入到设备中。 无法读取或更改设备的登录名和密码。 这比以前的选择要好，因为它不需要人与人之间的互动。
问题 。 除了第一个问题，所有问题仍然存在，但主要问题是
服务和Intranet之间的
同步 。 服务很多，尚不清楚如何同步它们-因此，我们无法实现第二种解决方案。 我们有在封闭网络中使用设备的客户。 我们发布了一个新的控制器，并将其出售给客户，并且他的系统已关闭。 它已设置，只能运行一次，并且很难进一步传达“秘密”。 批量报告？ 尽管技术上很简单，但组织中的一切都很复杂。
两种解决方案都不适合我们。 因此，我们决定采取不同的方法。 但是在此之前，他们决定概述共同的目标。
任务与目标
首先常见的任务。
认证方式 这是一种了解谁正在与顶级系统进行对话，谁与调度系统完全连接的方法。
身份验证不是在授予或限制访问权限，而是一种了解谁在与我们交谈的方式。
发送数据的任务 。 我们的控制器是专为特殊任务而设计的Linux计算机。 我们需要它们将数据发送到顶级系统，并通过VPN连接。 同时，我们希望调度能够“开箱即用”地工作-无需客户以及系统的最终用户与我们以及与客户之间的设置和交互。
其他任务 。 这是可靠的连接，数据通道加密，但是另一个问题是
授权 。 授权任务与外部服务相关联，分为三个部分。
- 免费制造商服务 。 通过设备序列号提供访问权限。
- 为合作伙伴提供的服务的序列号白名单 -将购买和访问链接到客户的帐户。
- 执照 根据证书中指定的选项允许或拒绝访问。
解决问题是我们要实现的目标。
向客户发行和交付 。 没有人的参与-信息是由生产中的机器人缝制的。
损失追回 。 我们希望绝不丢失任何秘密细节。
从生产到服务交付 。 我们想要没有它，因此您不需要向服务交付任何东西。 在启动新设备时，我们不想更新应该对这些设备进行身份验证的所有服务的数据库。
存储在服务器上 。 建议不要在此存储任何内容。
服务和Intranet之间的同步 。 建议不要同步任何内容-因为我们不会存储任何内容。
防止复制详细信息 。 我们想要一个秘密，要花钱，这是不可能免费复制和接收的。
数字签名急救
电子数字签名（EDS）是一项使我们一切正常的技术。
就像普通签名一样，只有数字签名。 EDS易于验证，但很难伪造。 密码学已经有数十年的历史了。
如果您知道秘密私钥（私钥），则电子签名就是消息可以计数的东西。 如果您知道公用密钥（公用密钥），则很容易验证消息的电子签名是否正确。 名字很清楚-公众习惯于告知所有人，而秘密仅适用于签名的人。
所有签名和密钥都只是数字。
在我们的例子中，这是32字节的数据，可用于数学“魔术”。 数学可确保签名易于验证，但难以伪造。
我们使用签名ECDSA-256 + SHA-256：
e = HASH(m) -密码哈希函数将消息m不可逆地转换为数字e；
private key (dA) -随机数；
public key (QA) -从私钥生成，但反之则不；
signature (r,s) = sign(private key, e) -签名;
verify(public key, signature, e) -签名的验证。
EDS认证。 第一次尝试
使用这种棘手的机制，对于一个简单的方向，而在另一个困难的方向上起作用，可以为我们的任务做什么呢？
向客户发行和交付 。 我们为生产中的每个设备生成一个随机私钥。 我们不会告诉任何人，因为我们甚至都不认识他，因此我们会写信给该设备。
从生产到服务交付 。 接下来，我们仅使用此设备的公钥对服务进行身份验证。 在服务方面，我们仅存储公共密钥列表而不是密码。
标准健康检查算法：
- 服务向控制器发送随机消息
m ；
- 控制器：
sign(private key, m) ；
- 控制器向服务发送签名；
- 服务：
verify(public key, signature, m) 。
我们以这种方式决定的唯一一件事是，我们
不再以开放或缓存的形式
将常见的“秘密”存储在我们的服务中。 这不是我们想要的。
EDS认证。 第二次尝试
我们不想在服务上存储任何东西。 为此，我们可以强制设备将其公钥发送给服务。
在最后阶段，我们解决了两个问题。 第一个-我们
检查了他们是否提供了服务的密钥 。 我们有一个公钥，这意味着我们也做了一个私钥。 第二个-我们确保
设备拥有私钥 ，该
私钥位于USB闪存驱动器上的某个位置。 如果设备可以签名，则它具有私钥。
现在，设备还将把公钥发送到服务。 如何检查没有人拦截他，没有伪造他以及一切正常？
检查公钥 。 我们为自己创建了另一个公钥。 他将是我们作为制造商的关键。 这是根密钥“根私钥+公钥”。 在生产中使用此根秘密密钥，我们将对设备公用密钥进行签名，并将此签名存储在设备上。 设备必须将其公钥和其公钥签名发送给服务。 现在，该服务可以检查设备的公钥。 如果使用根私钥签名，则我们将发布此密钥。
只有制造商-我们可以在设备上创建并存储签名，但请检查所有内容。
我们在“联系人”部分的网站上发布公钥。 任何人都可以拿走它并检查将设备发送到服务的设备的公钥。 然后，您可以验证设备本身具有自己的私钥。
通用算法如下所示。
(once) random root private key ；
factory: random device private key ；
factory: sign(root private key, device public key) = signature_1 ；
device->service: device public key + signature_1 ；
service: verify(root public key, signature_1, device public key)?
第二次尝试结果
我们解决了
交付给客户的问题-信息被存储在生产现场，
无需恢复任何东西 。
我们解决了
将“秘密”传递给顶级服务的问题非常重要，因为所有需要存储在服务中的都是制造商的公钥。 整个密钥为33个字节。 借助他们的帮助和数学魔术，您可以继续建立握手连接，并验证设备是否具有相应的私钥。
在服务器上，我们仅存储制造商密钥（根公共密钥）。
我们已经谈到过，
服务和Intranet之间没有
同步 。 同样，我们也无法
防止复制细节 。
我们唯一忘记的是
身份验证 。 该设备发送了一个私钥，我们检查了该私钥并发出了它，并检查了该设备是否拥有它。 但是我们不知道这是哪种设备，我们生产了数千种。
因此，我们应用了一个称为“证书”的技巧。
认证和证书
在这一步中，在所有带有签名及其检查的数学魔术中，我们添加
其他信息-证书 。 为此，我们不仅要在工厂登录公钥（设备公钥），还要在密钥中附加其他信息。
在我们的案例中的其他信息。
- 生产日期和制造商。
- 型号和硬件配置。
- 可以验证设备的序列号。
- 选项：硬件和软件。 不同的配置在物理上可能不会彼此不同，但是证书将包含有关客户所支付费用的信息。
- 客户名称和帐号。
我们将使用生产者密钥-根公共密钥将所有这些信息与公共密钥一起签名。 之后，信息将转到服务，他们将能够确保信息正确。 由于这些是我们和合作伙伴的服务，因此他们信任我们。
目标状态
信息也在工厂缝制，无需
交付服务。
在服务器上，我们仅存储制造商的密钥。
损失追回 。 我们将证书中的所有信息都缝到设备的闪存中。 从理论上讲，它可以被意外或有意删除，但是证书中的此信息没有什么秘密。 甚至签名本身也不是秘密-有公共密钥，并且带有我们密钥的签名。 证书中的唯一秘密是具有不同选项的设备的销量。
证书可以存储在工厂中，如果丢失，则将其发送给客户。 客户端很少专门擦除内存的服务区域。 通常，我们在设备恢复过程中执行此操作：设备是从客户端到达的，它已完全通过初始化传递，所有内容都被删除，再次下载，然后从工厂数据库复制了证书。
我们没有丢失
恢复 ，复制保护和
服务之间的同步 。
在认证阶段，我们接收并验证证书。 我们了解这是什么类型的设备-我们知道制造商，型号和序列号，以及他能或不能做什么。
登入
证书允许您存储授权信息。
免费制造商服务 。 知道设备的序列号，您便可以访问所有人。 在我们的服务中，我们可以访问所有基本客户。
白名单的序列号 。 为了给我们的合作伙伴提供服务，您可以创建一个带有序列号白名单的表格：“客户从我们这里轻松地购买了两个控制器，这些控制器的序列号与他的帐户相关联”
执照 您可以预先出售一些东西，然后
根据证书中指定
的选项（具有系统X许可证的控制器）允许或拒绝访问。
服务，系统的制造商或制造商之间没有共同的基础。 当一切在系统中进行身份验证时，所有内容都仅由我们作为制造商签名的控制器上的信息起作用。
中级证书
我们在旅途中解决的另一个技术问题。 在我刚才提到的方案中，有制造商的根证书-根私钥。 每次创建设备时都需要它。 但是，如果有许多设备，则此密钥需要对有限的人群持续访问。 这很糟糕，因为如果丢失了它，则必须更新所有服务上的公钥，并且它不应被攻击者使用。 这些是组织上的大问题。 但是有一个解决方案。
我们将中间密钥引入一批不太容易丢失的设备。
我们做了同样的事情，只是链条更长。
凭制造商的证书，我们在中间密钥上签名。 从物理上讲，这是一个“闪存驱动器”，在工厂交给领班一天。 硬件限制了密钥可以签名的设备数量。 在该方案的中间，我们添加了一个中间证书，否则没有任何变化。
安全密钥库
在所有这些方面，我们没有
为设备的私钥提供足够的
保护 -这仍然是USB闪存驱动器上的文件。 攻击者可以复制它，但很可能会丢失它或意外打开访问权限。
在理想情况下，最好防止设备的私钥被复制-将其放在黑盒中。
黑匣子执行4个操作：
- 内部本身根据请求生成密钥，但不提供；
- 提供公钥；
- 签名消息
- 验证签名。
要验证签名，您只需要一个公共密钥，因此三个操作就足够了。以我的理解，这应该是一种硬件解决方案，最好与处理器分开。 有多种选择，最好的是
在SoC内部或作为单独的芯片使用
特殊的加密处理器 。
我们审查的第一个黑匣子选项是我们使用的NXP i.mx 6、7、8处理器中的CAAM
模块 。 问题在于它是在处理器的Boot ROM中以编程方式实现的。
它可能包含可以通过其他处理器功能找到甚至利用的错误。 几年前，在此模块中发现了一个漏洞，使下载固件时可以绕过签名验证。 这不是我们需要的功能，但沉积物仍然存在。 另一个问题是，很难将带有此模块的处理器导入俄罗斯；它们需要填写文书。
因此，我们采用了单独的芯片。 老实说，我指望这样的事实：如果我们不能将它带到俄罗斯，我们会想出一些办法-芯片很小，价格为1美元。 但是一切都很好-他们找到了已经有所有论文的
Microchip ATECC芯片。
芯片ATECC608A
这是一个单独的小芯片，需要花费一分钱。 芯片通过I2C连接-处理器的两个“分支”，您也可以与其他外围设备共享。 该芯片具有标准引脚排列。 我们在设备的第一个版本中使用了该芯片，并将其焊接在具有相同协议和引脚排列的另一芯片上，因为这是标准的。
该芯片可以完成我们需要的此类芯片：读取签名，存储密钥等等。
特点
- 16个按键槽；
- 可以读取ECSDSA签名，哈希，MAC和加密AES，可以DH；
- 有一个随机数发生器和密码计数器；
- 外壳：SOIC-8，DFN6;
- 协议：I2C，单线；
- ~0.7$@1000片
如何使用微电路
有不错的
文档 ，但是在NDA下。 如果您立即写信给gamma.spb.ru，那么他们将在2周内将其给您。 如果在另一家公司-3个月后。 我们写信给两家公司，当我们完成所有工作后，另一位Microchip经销商回答了我们。
应用笔记很少 ，而且比平均水平还差。
GitHub上有
软件 -具有HAL的库。 很好笑-该文档位于NDA下，其上编写的软件位于GitHub上。 该软件不支持Linux，但是支持Raspberry Pi和Atmel MK-有点不同。 开发人员认为，在所有设备上只有一条I2C总线，例如，在Raspberry Pi上称为支脚。
与
OpenSSL 集成 -不能很好地工作，但是可以。
Linux下没有示例，也无法进行
个性化设置 。
芯片定制
个性化是芯片最大的麻烦。
问题在于该芯片可以完成很多事情。 它有16个插槽，其中存储了16个密钥：用户数据或公共密钥，或其他插槽的临时存储-有很多选项。
您需要以某种方式限制对插槽的访问，并且还有许多配置选项：通过密码，通过另一个插槽中的身份验证，通过访问工厂的时间进行限制。
在表中，键的类型，读写访问权限，插槽之间的关系-SlotConfig，KeyConfig。在我们使用的每个密钥的位掩码（16位）中，到处都有不同的数字。
最可悲的是，配置区域是一次性的，它设置了插槽的功能。 在做正确的事情之前，我们弄乱了50个筹码。 该芯片仅
在锁定配置后才能工作。 另外，
每个插槽都有一个
锁示例或软件中没有文档。 有单个位的文档，但是那里的一切都很复杂。 在Microchip的所有示例中都写着：“下载这样的块，它将以某种方式为您工作，就像向Amazon发送数据的示例一样。”
这花费了很多时间，但是在此过程中，他们做了一个很酷的实用程序。
Atecc-util实用程序
这是一个控制台实用程序，可以执行芯片的大部分功能，并使其变得更容易使用。 根据MIT许可，它可以
在GitHub上使用。
该实用程序使用CryptoAuthLib。 她知道如何在配置区域中更友好地工作，她知道如何与SHA，MAC，ECDSA和DH一起工作。 该界面是批处理友好的，因为我们首先创建了用于脚本的实用程序。 一个人可以引起它的事实是一个附带特征。 该实用程序可以列出一个列表-命令计划：“首先，个性化该区域，然后写下这样的密钥。”
调用实用程序的示例非常容易理解。
atecc - b 10 - c 'serial' - c 'read-config /tmp/config.dump'
该实用程序在Linux下，AMD64下构建-它在Debian软件包中。
其他个性化工具
我们有一个Excel标牌来读取这些位。 如果您向我们展示了使用Microchip进行的NDA扫描，我们将把它交给您。
我们涵盖了所有测试内容，因为有很多选项可以让您忘记一位，而某些服务命令将读取您的私钥。 测试测试真实设备。 他们转向微电路并检查设备上的正确配置：是否可以读取此插槽，可以进行签名？
与这些位并行，我们创建了该设备应满足的保证的列表，并检查了所有工作方式。 我们使用
蝙蝠框架 -非常有趣的事情。 看起来像这样。
示例的测试列表。 较高的通过了，较低的没有通过。设备中的设置
对于我们自己，我们仅使用两个插槽来执行我正在谈论的任务。 在这两者中，我们存储设备的私钥。 区别在于前者与
永久证书相关联，该
证书于1970年颁发了200年。
这是由于以下事实：在物联网中，时间并不总是同步的。 证书基础结构涉及验证证书的有效性。 如果设备上的同步中断，则某些重要服务可能会失败，例如VPN。
因此，
一个插槽是无限永久的 。 它仅生成一次，并且在设备的整个生命周期中都不会改变。 对于此密钥，将为封闭网络生成200年的证书。
另一个插槽正在更新。 证书的最长有效期为一年。 这样做是为了以防万一。 随着设备证书的有效期到期，将生成私有可更新设备密钥。 用于开放网络中的身份验证，每月更新一次或更少一次，并附带证书。
对于用户，我们生成了各种组合 ，包括用于ECDSA专用密钥的多个插槽。 如果用户不信任我们的私钥，则可以在单独的插槽中生成其密钥。 为此，您只需要信任Microchip。 用户可以阅读签名，进行加密-我们提供了芯片可以做的一切。
不幸的是，到目前为止，还没有人使用过，但我们希望如此。
基础结构：中级密钥
我已经说过，在某些时候，我们实施了中间证书，以免与不应丢失的根证书保持一致。 他从没出现在工厂。
物理中间证书是ATECC508A芯片。 它与608略有不同，但是在508中，有一些功能对于按键很方便，但是在608中，它不再存在。
该芯片通过USB-I2C适配器连接。 这是带有tiny-usb-i2c固件的USBISP-一个可以闪入USB-I2C桥接器的编程器。 中间证书使用其私钥对设备证书进行签名。
事实证明，微电路的两个功能对我们有用。
硬件密码保护插槽 。 只有满足以下两个条件，才能对芯片进行编程以读取签名：
我们为工头提供了用于多个控制器的中间键和密码。 因此，您需要同时窃取密钥和密码才能获得访问权限。 我们免费获得了此机会，但它提高了系统的安全性。
硬件对使用次数的限制 。 内部的密码计数器只能增加。 当它一次达到预定极限时，微电路不会对其他任何东西进行签名。
客户端上的OpenSSL
让我们考虑一下一切如何在客户端上进行。 控制器上有OpenSSL。 我们没有发明任何东西-这是普通的TLS，普通的PKI。 我们还需要一个客户端库。 在绝大多数Linux软件中，它用于安全连接。
我们从Microchip那里获取了代码，并添加了一点代码，支持全新的OpenSSL。
1.1。 结果，他知道如何使用硬件密钥-硬件支持私钥的密码。
看起来像这样。
openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device AP6V5MDG.csr
这是对常规OpenSSL的调用，也是使用适当的引擎模块的说明。 在此处设置密钥：地址，型号和最后两个字节是所使用的插槽号。 一切都像是密钥文件一样传输，但不是文件-您需要进入设备。
服务器上的SSL
任何SSL均可在服务器上使用，包括OpenSSL。 无需在服务器端进行任何修改和自定义构建。 服务器上需要做的就是
能够检查证书捆绑链 （设备证书+中间证书），并
存储我们在站点上发布的
公共密钥 -Wiren Board ROOTCA。
标准TLS表示，双方都必须相互认证。 — — . — handshake.
: . , . letsencrypt SSL, , .
, — MQTT.
MQTT: mosquitto
IBM. .
Mosquitto — , , Linux. , OpenSSL engine ( ) «keyfile», .
, 20 .
bundle.
.
mosquitto_sub -h mqtt.wirenboard.com -p 8884 -cert /etc/ssl/device/device_bundle.crt.pem --key 'engine:ateccx08:ATECCx08:00:04:C0:00' --capath /etc/ssl/certs/ -t /# -v
. —
-cert . bundle- — .
--key . .
,
--capath , . SSL-, letsencrypt.
.
root@wirenboard-AXXVJI62:~# cat /etc/mosquitto/conf.d/bridge-hw.conf connection wb_devices_cloud.wirenboard-AXXVJI62 address contactless.ru:8884 bridge_capath /etc/ssl/certs/ bridge_certfile /etc/ssl/device/device_bundle.crt.pem bridge_keyfile engine:ateccx08:ATECCx08:00:04:C0:00 notifications true notification_topic /client/wirenboard-AXXVJI62/bridge_status topic/# both 1 ""/dient/wirenboard-AXXVJI62
Mosquito- .
Mosquitto — .
per _listener_settings true listener 8884 0.0.0.0 cafile/etc/mosquitto/certs/WirenBoard_Root_CA.crt certfile /etc/letsencrypt/live/contactless.ru/fullchain.pem keyfile/etc/letsencrypt/live/contactless.ru/privkey.pem require.certificate true use_identity_as_username true password_file /etc/mosquitto/passwd.conf allow_anonymous false acl_file /etc/mosquitto/ad.conf :~$ cat /etc/mosquitto/acl.conf pattern write /client/%u/# pattern read /client/%u/#
— .
- Root CA letsencrypt- — . .
- Mosquitto.
username MQTT.
- , , , (CN) wirenboard-AXXVJI62, , .
per_listener_settings: , / (>1.5.5).
MQTT- Wiren Board IoT Cloud Platform.
OpenVPN
OpenVPN , , . , .
OpenVPN
, . , : bundle, , engine.
openvpn --capath /etc/ssl/certs/ --cert /etc/ssl/device/device_bundle.crt.pem --key engine:ateccx08:ATECCx08:00:04:C0:00
letsencrypt.
ca /etc/openvpn/WirenBoard_Root_CA.crt cert /etc/letsencrypt/live/vpn1.wirenboard.com/fullchain.pem key /etc/letsencrypt/live/vpn1.wirenboard.com/privkey.pem
— . - .
Nginx的
. Nginx , , , SSL. nginx web-, reverse-proxy. — nginx.
nginx , HTTP-, . , : Common Name, , . , 400.
ssl_client_certificate WirenBoard_Root_CA.crt; ssl_verify_client on;
nginx . — , HTTP. Linux- nginx , SSL, , OpenSSL.
wget , bash , HTTP- TLS . 10 .
server { listen 8080; location / { proxy_pass https://example.com; proxy_ssl_name example.com; proxy_ssl_server_name on; proxy_ssl_certificate/etc/ssl/device/device_bundle.crt.pem; proxy_ssl_certificate_key engine:ateccx08;ATECCx08:00:04:C0:00; } }
Wiren Board 6 , . , .
web- cloud.wirenboard.com OpenVPN . Grafana InfluxDB, MQTT. saymon.info — (MQTT) .
, - , , Grafana, MQTT-, , , . — .
, , :
— OpenSSL ,
— . !
InoThings Conf 2019 . YouTube- 2019 . Telegram. , , IoT.