Download FreeRTOS

Quality RTOS & Embedded Software

Simplifying Authenticated Cloud Connectivity for Any Device.
Designing an energy efficient and cloud-connected IoT solution with CoAP.
Introducing FreeRTOS Kernel version 11.0.0:
FreeRTOS Roadmap and Code Contribution process.
OPC-UA over TSN with FreeRTOS.

X.509 Certificates

When communicating securely across the internet, the client (IoT device) and the server must provide proof of their identity prior to establishing a mutually authenticated TLS connection. In a public key infrastructure, digital (or identity) certificates are exchanged to verify each entity's identity. The X.509 certificate is the most common digital certificate format and is widely used across the internet and in IoT use cases. The X.509 certificate is exchanged during the TLS handshake process, making it a critical piece of establishing a TLS connection. In IoT use cases, data transfer over communication protocols such as HTTPS or MQTT should occur only after a TLS connection has been established.

In PKI, a signature’s authenticity is established through a key pair: a public key and a private key. Public keys are disseminated widely, while private keys are known only to the owner; this is done to maintain security across the system. When data is signed or encrypted with a private key, any recipient of the data can authenticate and/or decrypt the data using the matching public key. Data encrypted using a public key can only be decrypted by the holder of the private key.

Once a key pair has been generated, a client will apply to a certificate authority for an X.509 certificate, using a certificate signing request (CSR). The X.509 certificate is either signed by a CA (certificate authority) or is self-signed. In most use cases, the X.509 certificate is only self-signed when it is the certificate of the root CA. In IoT use cases, it is more common (and better practice!) for an intermediate CA (instead of the root CA) to sign each end-entity’s certificate. This prevents the risk of exposing the root certificate. Using intermediate certificates creates a chain of trust that can be traced from the root CA to each end-entity.

Additional details can be found here: X.509 RFC5280.

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.