Set up and troubleshoot AWS IoT Greengrass with client devices
Created by Marouane Sefiani and Akalanka De Silva (AWS)
Environment: PoC or pilot | Technologies: IoT | AWS services: AWS IoT Greengrass; AWS IoT Core |
Summary
AWS IoT Greengrass is an open-source edge runtime and cloud service for building, deploying, and managing Internet of Things (IoT) software on edge devices. Use cases for AWS IoT Greengrass include:
Smart homes where an AWS IoT Greengrass gateway is used as a hub for home automation
Smart factories where AWS IoT Greengrass can facilitate ingestion and local processing of data from the shop floor
AWS IoT Greengrass can act as a secure, authenticated, MQTT connection endpoint for other edge devices (also known as client devices), which otherwise would typically connect directly to AWS IoT Core. This capability is useful when client devices do not have direct network access to the AWS IoT Core endpoint.
You can set up AWS IoT Greengrass for use with client devices for the following use cases:
For client devices to send data to AWS IoT Greengrass
For AWS IoT Greengrass to forward data to AWS IoT Core
To take advantage of advanced AWS IoT Core rules engine features
These capabilities require installing and configuring the following components on the AWS IoT Greengrass device:
MQTT broker
MQTT bridge
Client device authentication
IP detector
In addition, published messages from client devices must be in JSON format or Protocol Buffers (protobuf)
This pattern describes how to install and configure these required components, and provides troubleshooting tips and best practices.
Prerequisites and limitations
Prerequisites
An active AWS account
Two client devices running Python 3.7 or later
One core device running Java Runtime Environment (JRE) version 8 or later, and Amazon Corretto 11
or OpenJDK 11
Limitations
You must choose an AWS Region where AWS IoT Core is available. For the current list of Regions for AWS IoT Core, see AWS Services by Region
. The core device must have at least 172 MB RAM and 512 MB of disk space.
Architecture
The following diagram shows the solution architecture for this pattern.
The architecture includes:
Two client devices. Each device contains a private key, a device certificate, and a root certificate authority (CA) certificate. The AWS IoT Device SDK, which contains an MQTT client, is also installed on each client device.
A core device that has AWS IoT Greengrass deployed with the following components:
MQTT broker
MQTT bridge
Client device authentication
IP detector
This architecture supports the following scenarios:
Client devices can use their MQTT client to communicate with one another through the core device’s MQTT broker.
Client devices can also communicate with AWS IoT Core in the cloud through the core device’s MQTT broker and the MQTT bridge.
AWS IoT Core in the cloud can send messages to client devices through the MQTT test client and the core device’s MQTT bridge and MQTT broker.
For more information about the communications between client devices and the core device, see the Additional information section.
Tools
AWS services
AWS IoT Greengrass is an open source Internet of Things (IoT) edge runtime and cloud service that helps you build, deploy, and manage IoT applications on your devices.
AWS IoT Core provides secure, bidirectional communication for internet-connected devices to connect to the AWS Cloud.
AWS IoT Device SDK
is a software development kit that includes open-source libraries, developer guides with samples, and porting guides so that you can build innovative IoT products or solutions on your choice of hardware platforms. AWS Identity and Access Management (IAM) helps you securely manage access to your AWS resources by controlling who is authenticated and authorized to use them.
Best practices
The payload of the messages from client devices should be in either JSON or Protobuf format in order to take advantage of the advanced features of the AWS IoT Core rules engine, such as transformation and conditional actions.
Configure the MQTT bridge to allow bidirectional communication.
Configure and deploy the IP detector component in AWS IoT Greengrass to ensure that the core device’s IP addresses are included in the subject alternative name (SAN) field of the MQTT broker certificate.
Epics
Task | Description | Skills required |
---|---|---|
Set up AWS IoT Greengrass on your core device. | Install the AWS IoT Greengrass Core software by following the instructions in the developer guide. | AWS IoT Greengrass |
Check the status of your installation. | Use the following command to check the status of the AWS IoT Greengrass service on your core device:
The expected output of the command is:
| General AWS |
Set up an IAM policy and attach it to the Greengrass service role. |
| General AWS |
Configure and deploy required components in the AWS IoT Greengrass core device. | Configure and deploy the following components:
| AWS IoT Greengrass |
Confirm that the MQTT bridge allows bidirectional communication. | To relay MQTT messages between client devices and AWS IoT Core, configure and deploy the MQTT bridge component and specify the topics to relay. Here’s an example:
| AWS IoT Greengrass |
Confirm that the auth component allows client devices to connect and publish or subscribe to topics. | The following
| AWS IoT Greengrass |
Task | Description | Skills required |
---|---|---|
Install the AWS IoT Device SDK. | Install the AWS IoT Device SDK on client devices. For a full list of supported languages and the associated SDKs, see the AWS IoT Core documentation. For example, the AWS IoT Device SDK for Python SDK is located on GitHub
Alternatively, you can install the SDK from the source repository:
| General AWS IoT |
Create a thing. |
| AWS IoT Core |
Download the CA certificate from the Greengrass core device. | If you expect the Greengrass core device to work in offline environments, you have to make the Greengrass core CA certificate available to the client device so it can verify the MQTT broker’s certificate (which is issued by the Greengrass core CA). Therefore, it is important to obtain a copy of this certificate. Use one of the following approaches to download the CA certificate:
| General AWS |
Copy credentials in the client devices. | Copy the Greengrass core CA certificate, the device certificate, and the private key in the client devices. | General AWS |
Associate client devices with the core device. | Associate client devices with a core device so that they can discover the core device. The client devices can then use the Greengrass discovery API to retrieve connectivity information and certificates for their associated core devices. For more information, see Associate client devices in the AWS IoT Greengrass documentation.
The client devices that you associated can now use the Greengrass discovery API to discover this core device. | AWS IoT Greengrass |
Task | Description | Skills required |
---|---|---|
Send data from one client device to another client device. | Use the MQTT client in your device to publish a message on the | General AWS |
Send data from the client device to AWS IoT Core. | Use the MQTT client in your device to publish a message on the In the MQTT test client, subscribe to the topic that the device is sending messages on, or subscribe to # for all topics (see details). | General AWS |
Send messages from AWS IoT Core to client devices. | On the MQTT test client page, in the Publish to a topic tab, in the Topic name field, enter the topic name of your message. In this example, use | General AWS |
Troubleshooting
Issue | Solution |
---|---|
Unable to verify server certificate error | This error occurs when the MQTT client cannot verify the certificate that’s presented by the MQTT broker during the TLS handshake. The most common reason is that the MQTT client doesn’t have the CA certificate. Follow these steps to make sure that the CA certificate is provided to the MQTT client.
|
Unable to verify server name error | This errors occurs when the MQTT client can’t verify that it’s connecting to the correct server. The most common reason is that the IP address of the Greengrass device isn’t listed in the SAN field of the certificate. Follow the instructions in the previous solution to obtain the MQTT broker certificate and verify that the SAN field contains the IP address of the AWS IoT Greengrass device, as explained in the Additional information section. If not, confirm that the IP detector component is installed correctly and restart the core device. |
Unable to verify server name only when connecting from an embedded client device | Mbed TLS, which is a popular TLS library used in embedded devices, currently supports DNS name verification only in the SAN field of the certificate, as shown in the Mbed TLS library code. Because the core device doesn’t have its own domain name and depends on the IP address, TLS clients that use Mbed TLS will fail the server name verification during the TLS handshake, causing a connection failure. We recommend that you add the SAN IP address verification to your Mbed TLS library at the x509_crt_check_san function |
Related resources
Implementing Local Client Devices with AWS IoT Greengrass
(AWS blog post)
Additional information
This section provides additional information about the communications between the client devices and the core device.
The MQTT broker listens on port 8883 in the core device for a TLS client connection attempt. The following illustration shows an example MQTT broker’s server certificate.
The example certificate displays the following details:
The certificate is issued by the AWS IoT Greengrass Core CA, which is local and specific to the core device; that is, it acts as a local CA.
This certificate is automatically rotated every week by the client auth component as shown in the following illustration. You can set this interval in the client auth component configuration.
The subject alternative name (SAN) plays a critical role in the server name verification on the TLS client end. It helps the TLS client ensure that it connects to the correct server and helps avoid man-in-the-middle attacks during TLS session setup. In the example certificate, the SAN field indicates that this server is listening on localhost (the local Unix domain socket), and the network interface has the IP address 192.168.1.12.
The TLS client uses the SAN field in the certificate to verify that it’s connecting to a legitimate server during server verification. In contrast, during a typical TLS handshake between an HTTP server and a browser, the domain name in the common name (CN) field or SAN field is used to cross-check the domain that the browser is actually connecting to during the server verification process. If the core device doesn’t have a domain name, the IP address included in the SAN field serves the same purpose. For more information, see the Subject Alternative Name section
Th IP detector component in AWS IoT Greengrass ensures that the correct IP addresses are included in the SAN field of the certificate.
The certificate in the example is signed by the AWS IoT Greengrass device acting as a local CA. The TLS client (MQTT client) isn’t aware of this CA, so we must provide a CA certificate that looks like the following.