|Hint: Use the tree menu to navigate groups of related pages|
When communicating securely across the internet, the client (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 format of digital certificates and is widely used across the internet and 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 are handled through a key pair: a public key and a private key. A public keys is disseminated widely while private keys are known only to the owner to maintain security across the system. Messages that are transmitted are signed by the public key, but once received, the messages are decrypted by the user’s private key to read the message contents. Once a key pair has been generated, a client will apply to a certificate authority through a certificate signing request (CSR) to apply for an X.509 certificate. The X.509 certificates is signed either 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 to prevent the risk of exposure of the root certificate. By using intermediate certificates, this 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