Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

LibrariesinsideTransport Interface

Updated Mar 2025

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 infrastructureexternal_link, digital (or identity) certificatesexternal_link are exchanged to verify each entity's identity. The X.509 certificateexternal_link 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 processexternal_link, 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 authorityexternal_link) or is self-signed. In most use cases, the X.509 certificate is only self-signed when it is the certificate of the root CAexternal_link. 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 trustexternal_link that can be traced from the root CA to each end-entity.

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