The Internet of Things on AWS – Official Blog

Simplify multi-account device provisioning and certificate authority registration when using AWS IoT Core

Customers often manage multiple AWS accounts to separate their development, staging, and production environments. When deploying IoT workloads on AWS IoT Core, customers usually use unique X.509 certificates for identifying devices and certificate authorities (CAs) for validating the signature of device certificates during provisioning. In this blog, we will demonstrate how to use the newly launched capability of AWS IoT Core to simplify both device provisioning and CA registration for customers that use multiple accounts.

In the prior version, customers that manage different AWS accounts to differentiate between development and production workloads had to configure multiple CAs to connect the same device to multiple accounts during the development process. With this update, you can use the same CA across various accounts to simplify device provisioning when using Just-in-Time Provisioning (JITP) and Just-in-Time Registration (JITR) and improve security posture by having fewer CAs.

This update also simplifies the CA registration process for AWS IoT Core to validate the signature of device certificates during provisioning. Previously, to prove ownership before registering the CA, you had to have access to the CA’s private key. However, these private keys are typically managed by device vendors or security teams of organizations that operate their own CAs, and are not shared with the developers, which makes it challenging for developers to prove ownership of the CAs. With this update, your development team can directly manage the registration of CAs and simplify the device provisioning process.

The new capability is specific to JITP and JITR provisioning methods that automatically provision devices on their first attempt to connect to AWS IoT Core and enhances these methods for multi-account use cases. In contrast, Multi-Account Registration (MAR) of device certificates enables customers to move devices between different AWS accounts without registering CA, but requires registering device certificates on AWS IoT Core for each account manually.

Customers are already benefiting from the new capabilities

The ability to register CAs in multiple accounts and simplification of CA registration with AWS IoT Core reduces complexity for customers and helps accelerate time-to-market.

iRobot: reducing the complexity of device identity provisioning in multi-account environments

iRobot

iRobot designs and builds robots that empower people to do more inside and outside the home. iRobot uses multiple AWS accounts to separate their development, testing, and production environments. “With the new capability of AWS IoT Core to register CA certificates in multiple accounts, we can provision identities on our development robots once and move them among the approved development accounts as needed without re-provisioning. This simplifies the development process, which in turn helps improve our security posture because we can have tighter control over the reduced number of CAs and associate the CAs with security boundaries,” said Ben Kehoe, Cloud Architect at iRobot.

WirelessCar: accelerating time-to-market by simplifying security configuration

wirelessCarWirelessCar is one of the world’s leading innovators of digital vehicle services. They turn vehicle data into business value for consumers, mobility providers, vehicle makers, and society. WirelessCar uses Just-in-Time Provisioning for automating the provisioning of vehicles with X.509 certificate-based identities. “The new simplification of the CA registration with AWS IoT Core helps our developers move faster without waiting for verification certificates from our security team,” said Henrik Strömberg, Solution Architect at WirelessCar. “Our security team can keep the strong security posture without becoming the bottleneck in our fast-paced development environment.”

Getting started

The new capability allows registering a CA certificate in multiple accounts of the same region (and, of course, across multiple regions, which was possible before) without proving the ownership of the CA’s private key. The capability is unlocked if a device can send the Server Name Indication (SNI) field, which communicates the endpoint it is attempting to connect to at the start of the Transport Layer Security handshaking process. The new capability enhances JITP and JITR device provisioning methods. You can now register CA certificates in one of the following two modes:

  • DEFAULT: register a CA certificate with a verification certificate
  • SNI_ONLY: register a CA certificate without a verification certificate

AWS IoT Core registers device certificates in SNI_ONLY mode when you register the signing CA in SNI_ONLY mode.

Key points:

  • Only one account can register a CA in DEFAULT mode in one region.
  • Multiple accounts can register the same CA in SNI_ONLY mode in the same region. There is no limit on the number of accounts in the region where such CA is registered.
  • Multiple accounts can register the same CA in either DEFAULT or SNI_ONLY modes if these accounts are in different regions — this was possible before.
  • A CA can be in different modes across accounts. For example, one account can register it in DEFAULT mode and another account in SNI_ONLY mode.
  • In a given account, a CA can exist in only one mode. To change the mode of the registered CA, you need to delete the CA and register it again.

Let’s look at setting up this new feature and testing it in your accounts. We will show that we can register the same CA in multiple accounts through the following steps:

  • We will set up Cloud9 instances in two different accounts
  • We will set up CA in the first account in DEFAULT mode
  • We will set up CA in the second account in SNI_ONLY mode
  • Verify that the CA is registered in both accounts to validate the feature

Solution architecture

solution Architecture

Solution architecture – Figure 1

Solution overview and implementation

Creating the test environment

Use the Get Started With IoT workshop to set up the AWS Cloud9 environment quickly. Pick any AWS region closest to your location. In this blog, we will use US-EAST-1. Set up two Cloud9 environments in the same region but two different accounts because we will test the multi-account nature of the introduced capability. After completing the setup using the AWS CloudFormation template from the workshop, let’s begin setting up certificate authorities. Open the Cloud9 terminal (see the hint here), and let’s set up the first CA certificate.

Setup CA in Account 1

Let’s set up CA in this first account in DEFAULT mode. To register a DEFAULT CA certificate, follow our existing publicly available API docs here.

Create a CA certificate

openssl genrsa -out rootCA.key 2048

You should see a similar output:

e is 65537 (0x010001)
Generating RSA private key, 2048 bit long modulus (2 primes)
................................................................................................................................................................................+++++
..+++++

Now, let’s create a config file to generate a CA certificate through OpenSSL. Create a file named rootCA_openssl.conf with the following contents:

[ v3_ca ]
basicConstraints = CA:TRUE

This config file explicitly states that the certificate to be generated is a CA and not a leaf certificate. Once the rootCA_openssl.conf file is created, let’s run the following commands to generate the rootCA.pem file and fill in the details accordingly:

openssl req -new -sha256 -key rootCA.key -nodes -out rootCA.csr
openssl x509 -req -days 1024 -extfile rootCA_openssl.conf -extensions v3_ca -in rootCA.csr -signkey rootCA.key -out rootCA.pem

By now, we should have two files, rootCA.key and rootCA.pem. We will use them in the steps below.

Register CA

We derived the instructions from our publicly available document for registering your CA certificate. First, we get a registration code from AWS IoT Core. We will use this code as the Common Name of the private key verification certificate.

aws iot get-registration-code --region us-east-1

You should see a similar output:

{
  "registrationCode": "xxxxxxxxxxx7a60e19fxxxxxxxxxxxxxx8381dbd3457xxxxxxxxxxxxxx"
}

Now, let’s generate a key pair for the private key verification certificate. We will get a file called verificationCert.key.

openssl genrsa -out verificationCert.key 2048

You should see a similar output:

e is 65537 (0x01xxxx)
Generating RSA private key, 2048 bit long modulus (2 primes)
................................................................................................................+++++
.............................................+++++

Next, we will execute the following command to create a CSR for the private key verification certificate. We will get a file called verificationCert.csr.

openssl req -new -key verificationCert.key -out verificationCert.csr

Now, we need to set the Common Name field of the certificate with the registration code out from the earlier step. Populate the rest of the fields according to your details:

Country Name (2 letter code) [AU]:
State or Province Name (full name) []:
Locality Name (for example, city) []:
Organization Name (for example, company) []:
Organizational Unit Name (for example, section) []:
Common Name (e.g. server FQDN or YOUR name) []: XXXXXXXREGISTRATION-CODEXXXXXXX
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

We used the CSR to create a private key verification certificate. We will use this step’s verificationCert.pem file when we register the CA certificate.

openssl x509 -req -in verificationCert.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out verificationCert.pem -days 500 -sha256

Upon successful completion, we should see the following output:

Getting CA Private Key

Lastly, we will call the register-ca-certificate CLI command to register the CA certificate.

aws iot register-ca-certificate --ca-certificate file://rootCA.pem --verification-cert file://verificationCert.pem --set-as-active --allow-auto-registration --region us-east-1

Note: Take a note of the Certificate ID for use in the future verification step.

We should get a successful response with the returned Certificate ID and Certificate ARN.

After registering the CA certificate, you can still call UpdateCACertificate API or update-ca-certificate CLI command to update the registered CA certificate, if needed.

Now that we have registered the CA, let’s make a control plane call to AWS IoT Core’s endpoint and verify that it registered the CA. Run the following command (replace Certificate ID with the returned value from aws iot register-ca-certificate command):

aws iot describe-ca-certificate --region us-east-1 --certificate-id <<Certificate_ID>>

You should see a similar JSON output:

{
  "certificateDescription": {
    "certificateArn": "arn:aws:iot:us-east-1:YYYYYYYYYYYY:cacert/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "certificateId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "status": "ACTIVE",
    "certificatePem": "-----BEGIN CERTIFICATE-----xxxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n-----END CERTIFICATE-----\n",
    "ownedBy": "YYYYYYYYYYYY",
    "creationDate": 1655249872.319,
    "autoRegistrationStatus": "ENABLE",
    "lastModifiedDate": 1655249872.319,
    "customerVersion": 1,
    "generationId": "7xxxxxxxxxxxxxxxxxxxxxxxxxxxxe9",
    "validity": {
      "notBefore": 1655249071.0,
      "notAfter": 1743722671.0
    },
    "certificateMode": "DEFAULT"
  }
}

Setup CA in Account 2

Let’s open our second account and set up the Cloud9 environment as before.

Since we will register the same CA in the second account as we did in the first account, we will use SNI_ONLY mode. In this mode, we do not need to carry out verification steps as we did for the first account.

Please copy rootCA.pem file from account one and then run the following command:

aws iot register-ca-certificate --ca-certificate file://rootCA.pem --certificate-mode SNI_ONLY --set-as-active --allow-auto-registration --region us-east-1

Verify the CA has been registered

aws iot describe-ca-certificate --region us-east-1 --certificate-id <<Certificate_ID>>

You should see following output, which confirms the certificate mode is SNI_ONLY:

{
  "certificateDescription": {
    "certificateArn": "arn:aws:iot:us-east-1:ZZZZZZZZZZZZ:cacert/4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0",
    "certificateId": "4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0",
    "status": "ACTIVE",
    "certificatePem": "-----BEGIN CERTIFICATE-----xxxxxxxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n-----END CERTIFICATE-----\n",
    "ownedBy": "ZZZZZZZZZZZZ",
    "creationDate": 1655252314.053,
    "autoRegistrationStatus": "ENABLE",
    "lastModifiedDate": 1655252314.053,
    "customerVersion": 1,
    "generationId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "validity": {
      "notBefore": 1655249071.0,
      "notAfter": 1743722671.0
    },
    "certificateMode": "SNI_ONLY"
  }
}

Now you can use the CA certificate with SNI_ONLY certificate mode the same way as you would with DEFAULT mode.

Conclusion

We reviewed the new capability that simplifies registering the same CA certificate in two AWS accounts, alleviating the need to provision additional CAs when using multiple accounts, such as for development, testing, and production. We also demonstrated how to use SNI_ONLY certificate mode to register a CA certificate without the need for CA’s private keys, which simplifies the security configuration and accelerates time-to-market.

To learn more about CA registration, visit developer documentation, and to learn more about certificate mode, see the API documentation. To register the certificate manually, refer to the following developer documentation. To learn more about the SNI mode, refer to TLS extensions documentation.

About the Authors

Syed Rehan is a Global Sr. Specialist Solutions Architect at Amazon Web Services and is based in London. He is covering global span of customers and supporting them as lead IoT Solution Architect. Syed has in-depth knowledge of IoT and cloud and works in this role with global customers ranging from start-up to enterprises to enable them to build IoT solutions with the AWS eco system.
Victor Lesau is a Sr. Technical Product Manager at Amazon Web Services. He focuses on product strategy, roadmap planning, business analysis, customer engagement and other product management areas of AWS IoT Core and AWS IoT Identity services and smart home initiatives.