我正在使用多个传感器设备进行内部项目。我不希望用户单独注册每台设备。从某种意义上说，我想为注册到注册表的所有设备使用相同的公钥/私钥对，但能够通过 mqtt/http 将设备信息传递到 pubsub，并使用名称或 ID 等唯一设备信息。有可能实现吗？

我假设我是否使用相同的密钥。我将所有设备注册为一个，但是否可以将设备信息作为正在发布的消息的一部分发送。这样做会以任何方式（如 API）抑制谷歌内置功能的使用。

云技术的新手，任何想法/建议都会有所帮助。

我正在尝试使用 Google Cloud IoT Core 注册 IoT 设备，但在使用安装在 Google Cloud（设备注册表）上的 CA 证书签署设备公钥时遇到问题。

以下是谷歌的要求：

• CA 和设备证书必须是 X.509v3，以 base64 编码，包装在 -----BEGIN CERTIFICATE----- 和 -----END CERTIFICATE----- 中。
• CA 证书不需要自签名（“根 CA”）；设备证书必须由注册表级别的特定 CA 证书签名。
• Cloud IoT Core 拒绝未由注册表级证书签名的设备公钥。
• CA 和设备证书必须采用 PEM 格式

在通过 StackOverflow 和其他地方的先前响应之后，这是我迄今为止尝试过的（使用默认配置文件）：

选项1

1. openssl req -x509 -nodes -newkey rsa:2048 -days 365 -keyout ca.key -out ca.crt -subj "/CN=unused"
2. openssl req -nodes -newkey rsa:2048 -days 365 -keyout device.key -out device.csr -subj "/CN=unused"
3. openssl x509 -req -days 365 -in device.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out device.crt

选项 2

1. openssl req -new -x509 -nodes -days 365 -newkey rsa:2048 -keyout ca.key -out ca.crt -subj "/CN=unused"
2. openssl genrsa -out device.key 2048
3. openssl req -new -days 365 -key device.key -out device.csr -subj "/CN=unused"
4. openssl x509 -req -days 365 -in device.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out device.crt

在这两种情况下都可以正常创建证书，但是当我尝试使用此证书注册设备时，我收到一条错误消息，指出无法根据 CA 证书验证设备证书。

签署设备证书时我做错了什么？您可以忽略 Cloud IoT 配置，因为我已经验证它可以工作（没有 CA 证书）。

非常感谢！

有人知道当 Google Core IoT 上的设备离线时触发事件的简单方法吗？在我切换到谷歌的物联网实现之前，这很容易通过在 MQTT 断开连接时触发事件来处理，但谷歌似乎没有简单的方法来做到这一点。

有谁知道这方面有什么计划吗？

谁回来了，我需要从头开始让他们看到像这样的东西是物联网设备管理的基本要求！

AWS 和 Microsoft 等其他平台已经实现了此功能（或以某种方式轻松处理）： https ://docs.aws.amazon.com/iot/latest/developerguide/life-cycle-events.html

Auzure iot hub 的设备连接（在线/离线）状态

我希望在编写所有代码并使用谷歌的物联网平台实现我的设置之前就知道这一点，我想这是我的错，因为假设一些东西如此简单并且应该是物联网设备的标准。

如果您连基本的线下/线上活动都不能提供，您将如何与其他物联网提供商竞争？！

我在这个 SO question 中的回复显示了我如何必须编写 100 多行代码才能创建一个 firebase 函数来检查设备是否在线（但这仍然不能处理离线事件，并且只是对应该做的事情的 hack是任何物联网服务提供商的本地人！）： https ://stackoverflow.com/a/54609628/378506

我希望其他人已经找到了一种方法来做到这一点，因为我花了很多天搜索 SO、Google、Google Core IoT 文档，但仍然没有找到任何东西。

即使支持 MQTT Last Will，我们也可以完成这项工作，但 Google 也不支持 ( https://cloud.google.com/iot/docs/requirements ) ...来吧伙计们！

目前，我正在使用谷歌云服务对我的设备进行编程，作为物联网项目的一部分。

几乎一切都在工作，但不是全部。我为 Python 编辑了原始 MQTT 库，如果我将 JWT 令牌到期时间设置为少于 2 小时，它就开始正常工作

24 小时是 JWT 令牌的有效到期时间吗？或者我做错了什么？

我正在使用 Raspberry PI 3B+ 和 Python 3.6.7

我的 JWT 访问和刷新令牌与 Github 中 Google 库中的令牌相同。我的库仅在多个线程中运行它，以便我可以从同一设备创建多个连接。

编辑：我在函数中修改了这一行create_jwt...

至

我对 Google Cloud IoT Core和相关服务相当陌生，并且遇到了一个我找不到“最佳实践”解决方案的问题。

使用 Google Cloud IoT Core 从 IoT 设备接收遥测数据，检测 IoT 传感器设备何时离线或静音的最佳方法是什么？其他基于云的物联网服务实现具有用于生成警报的内置通知超时，但我找不到谷歌物联网的类似物

示例：许多 IoT Edge 设备监控冷藏室的温度，并通过 MQTT 或 HTTP 通过 WiFi 或移动数据连接每分钟将测量值推送到 Google Cloud IoT Core。如果测得的温度超过可接受的限制，则会触发警报消息，并将其发送给操作服务人员。

但是，如果某个 IoT Edge 传感器由于某种原因突然停止运行，Google Cloud IoT 服务如何检测到呢？显然，出现问题的唯一迹象是，没有从某个 DeviceID 接收到消息的时间长于配置的消息传递间隔，例如 2 x 间隔 + 宽限期，因此可以生成警报以警告缺少遥测数据，可能是由电源故障引起的，需要解决哪些问题？

是否有任何标准方法可以根据从设备接收到的（缺少）遥测数据自动维护每个设备的“物联网设备存在”状态，从而使状态改变（在线/离线转换）会导致生成警报消息吗？

或者是否需要单独的预定服务来迭代所有（假定为活动的）设备，测量自上次接收遥测（温度）更新以来的持续时间，并直接更新设备存在状态？

我有一个关于物联网设备密钥轮换的基本问题。

我们计划使用安全元素（示例）来生成密钥对。因此，密钥对是在物联网设备的芯片上生成的。

公钥最初上传到 Google IoT 后，如何执行密钥轮换？

使用现有的私钥，设备可以签署 JWT 并向 Google IoT 验证自己。在设备中生成新的密钥对后，JWT 是否也可以用于验证将新的公钥上传到注册表？

请分享此类平台的任何密钥轮换示例。谢谢！

为了在 Google Cloud IoT Core 中创建客户端，我最初只使用：

虽然，在许多文档代码示例中，我看到使用了下面给出的这种方式和另一种方式：

为了能够使用上述内容，我必须生成另一个 JSON 密钥。无法理解这两个客户之间的本质区别是什么。另外，我使用了第二种方法来获取设备的状态。

如何使用 MQTT 和 Google Cloud IoT Core 向注册表中的所有设备发送命令？

到目前为止，我看到的所有示例都只是将命令发送到单个设备。我是否必须在我的设备上循环并向每个设备发送消息？

提前致谢。

我有一个基于 Google Cloud Platform 的项目，其中涉及将 Raspberry Pi 设备添加到Google IoT注册表。我需要做的是为注册表和设备生成签名证书，以确保不注册欺诈设备。

我已经尝试过生成签名的 X.509 证书，如下所示：

请注意，当被提示时，我输入了额外的主题信息，如姓名、国家、电子邮件、组织，根据其他 SO 问题应该使其工作。

调用这些命令后，我最终得到以下文件：

所以我要做的是将ca.crt添加为注册表证书，然后当我尝试将 device.crt 作为设备证书上传（类型RS256_X509）时出现错误Certificate is not supported by Cloud IoT

我可能做错了什么？我想确保创建正确的证书并将它们链接到注册表和设备。

我正在开发内存受限的 IoT 设备，并希望通过 MQTT 将其连接到 Google IoT Core。必须信任以允许服务器 TLS 证书验证所需的根证书列表非常长。我正在寻找一个适合资源有限的物联网设备但不会突然停止工作的较小列表。有没有办法安全地减少这个所需证书的列表？

在“设备安全建议”部分下的在线文档（https://cloud.google.com/iot/docs/concepts/device-security）中，它指出：

'与 mqtt.googleapis.com:8883（或 :443）通信时使用 TLS 1.2，并使用根证书颁发机构验证服务器证书是否有效。阅读此安全说明，了解详细的 TLS 要求和未来兼容性。

从安全说明（https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html）它指出：

“至少必须信任https://pki.google.com/roots.pem中的证书。”

我可以清楚地看到文档指出完整列表是必需的，但这对于内存受限的物联网设备来说似乎是不可接受的。例如，AWS 只需要一个证书 - 取决于所选的 TLS 密码。请参阅服务器身份验证下的 AWS 文档 ( https://docs.aws.amazon.com/iot/latest/developerguide/managing-device-certs.html )

任何有助于了解可以减少根证书列表的方式（例如基于 ECC 的验证与基于 RSA 的验证的消除）都会有所帮助。