Certificate Management for Embedded Systems

(An Introduction to Public Key Infrastructure)

Asymmetric key establishment is fundamental for understanding digital certificates. These certificates use asymmetric algorithms to ensure secure key establishment, which is crucial for maintaining the data's integrity and confidentiality. If you're new to certificates and want to learn more, it's important to familiarize yourself with the basics of asymmetric key establishment. This will give you a solid foundation for understanding how certificates work and how they can be used to protect data in various scenarios.

Certificate Management is "All About the Trust"

When a browser establishes a secure connection with a server, the browser must trust the certificate being sent from the server. This is where the concept of a chain of trust comes into play. The browser trusts the certificate because it has a pre-installed copy of the root certificate, also known as a Certificate Authority (CA) certificate, in its certificate store. This root certificate acts as the foundation of trust for all other certificates that the CA issues. When the server sends its certificate to the browser during the initial asymmetric handshake, the browser checks to see if it trusts the root certificate -- i.e. if it has a pre-installed copy of the root certificate. If it does, then the browser can trust the certificate being sent from the server and establish a secure connection. Understanding this chain of trust is crucial for ensuring the integrity and confidentiality of data being transmitted over a secure connection.

Let's start with how a browser trusts a server. What you see in the video below is the chain of trust. Your browser trusts the certificate sent from the server to your browser during the initial asymmetric handshake because it walks the chain of trust, checking each certificate in the chain. The root certificate is trusted since it has a pre-installed copy in the certificate store.

You can open the Certificate Store on Windows as shown in the above video: select Run from the WinX Menu in Windows. Type certmgr.msc in the Run box and hit Enter. Follow the short exercise shown in the video using your browser and the certificate store.

When you arrive at a website, your browser, or more specifically, the TLS engine, starts validating the website's SSL certificate and then walks the complete chain all the way up to the root certificate. For example, realtimelogic.com is signed by an intermediate certificate, which in turn is signed by a root CA certificate. The root CA certificate is self-signed, and a copy of this certificate must be stored in your computer's certificate store for the complete validation process to succeed.

When designing an HTTPS server or client, it's important to ensure that the necessary certificates are in place to establish a secure connection. For an HTTPS server, this means having a certificate trusted by all browsers, which means that the browser must have a copy of the CA certificate that signed the server's certificate. On the other hand, if you're designing a TLS client such as an HTTPS client, your client must be able to validate the certificate received from the server during the initial asymmetric handshake. To do this, your client must have a copy of the CA certificate that signed the server's certificate. In the tutorial below, we'll go into more detail on how this process works and how you can ensure that your HTTPS server or client is set up for success.

Introduction to Asymmetric Algorithms

Asymmetric key algorithms simultaneously use private and public keys. The private key is known only to your host platform, while the public key is given by your host platform to any other device that wants to communicate securely with it.

The SSL protocol can use several asymmetric key algorithms, mainly RSA and ECCDH. RSA, an algorithm developed in 1977, is the most widely used algorithm. ECCDH is a newer technology that promises much faster processing at the same security level, which is paramount in embedded devices with limited CPU power. ECC is short for Elliptic Curve Cryptography. We will not go into the details of how these two algorithms function. You can find plenty of information on the Internet that describes RSA and ECC.

The following diagram shows a typical RSA key exchange. Bob wants to send an encrypted message to Alice.

Asymmetric Encryption

Alice starts by sending her public key (A's public) to Bob so Bob can use the public key to encrypt a message. Bob uses Alice's public key and encrypts a message. The encrypted message is sent to Alice. Only Alice can decrypt the encrypted message since only Alice has the private key. An eavesdropper will not be able to decode the encrypted message.

Besides providing one-way asymmetric encryption, the asymmetric key encryption algorithm can also be used for signing messages. Signature management is simply the reverse of one-way encryption.

Sending a Signed Messages

Alice wants to send a signed message to Bob. Alice encrypts the message by using her private key. The public key and the encrypted message are sent to Bob. Bob uses Alice's public key to decrypt the message. Alice's private key is only known to Alice, so no one else can use her private key to encrypt a message. For this reason, the signature is deemed valid if the decryption on Bob's side is successful. Note: anyone receiving the message sent from Alice can decrypt the message, so the asymmetric key encryption, when used for signing messages, does not provide any protection from, for example, eavesdropping. It's strictly used to verify the sender.

Although Bob decrypts the message and verifies that it comes from Alice, Bob has no electronic means of trusting Alice. If Bob and Alice had met in person before Alice sent the message, Alice could have physically given Bob her public key. Bob would then have been able to trust encrypted messages sent electronically from Alice. This is a fundamental problem with public key cryptography. The SSL protocol solves this problem by using a trusted third party. We will go into more detail on using a third party when we explain how SSL certificates work.

There are a few limitations with asymmetric key encryption. The data being encrypted cannot be larger than the key length. For example, an RSA key with a length of 1024 can theoretically not encrypt more than 1024 bits (128 bytes). The practical size is less than 128 bytes since the RSA encryption function requires some padding. Another limitation is the processing power required to perform the arithmetic.

Asymmetric encryption is typically used to encrypt short messages such as a signature or exchange of the symmetric key used by the SSL protocol. A signature is typically a digest of a message encrypted with the private key. A message digest is a hash of the data that requires a signature. The SSL protocol supports several hash algorithms, including SHA-256.

Signed Message Data

In the following example, Alice wants to send a signed message to Bob:

  1. Alice calculates a message digest of the data
  2. Alice encrypts the message digest using her private key
  3. Alice sends the data, the encrypted message digest, and the public key to Bob
  4. Bob decrypts the message digest using Alice's public key
  5. Bob calculates his own message digest on the received data and verifies that his calculated digest matches the decrypted message digest received from Alice

Signing messages is an important component of the SSL protocol as it makes it possible to provide trust management. A signature is a message digest encrypted with the subject's private key. The subject is Alice in the above example.

Introduction to Certificates

SSL provides trust management and encrypted and private communication. A known third party provides trust.

Alice wants to communicate with Bob, but she wants to know if Bob is trusted before doing so. The only way Alice can verify Bob's identity is to use a well-known, trusted third party. Bob's public certificate must be signed by the same well-known third party to provide trust. This third party is known as a Certificate Authority, or CA for short. Your browser or host platform generally contains a list of well-known CAs that it trusts. This CA list is pre-installed in your browser or host platform.

Certificate Components

In a typical SSL usage scenario, a server, in this case Bob, is configured with a certificate containing a public key and a matching private key.

The public key is embedded inside the public certificate and several other components that identify Bob as the certificate owner. All data in the certificate is signed using the CA's private key.

As we previously explained, a signature is a message digest signed with a private key. The signature algorithm type is also embedded in the certificate. An example of a signature algorithm is sha2WithRSAEncryption. This means the message digest is calculated using SHA-256, and the message digest is signed using RSA.

If Alice has a copy of the CA's public key, she can validate Bob's certificate by decrypting the message digest using the CA's public key. The certificate is deemed valid if the decrypted message digest matches the digest Alice calculates from all data in the certificate.

Alice starts by connecting to Bob. If Alice is a browser, and Bob is a server, then Alice connects to the domain name "Bob". The SSL/TLS handshake starts immediately after Alice successfully connects to Bob. Bob's public certificate is transferred to Alice during the TLS handshake phase.

Certificate Validation

Alice verifies that the certificate she received from Bob is valid by decrypting the message digest and by comparing the decrypted message digest with her own calculated message digest. The certificate is deemed valid if the two message digests match; however, she still does not trust Bob since she has not validated Bob's CA. Alice now uses the CA identification found in the received certificate and looks up the identity in her own CA list. Bob is trusted if Bob's CA is found in her own CA list. Alice will not trust Bob if Bob's CA is not found in Alice's CA list.

At this point, you may think that Alice trusts Bob, but one important security check remains. At this point, Alice has verified that the certificate received from Bob is valid and signed by a CA found in her own CA list. However, a person performing a man-in-the-middle attack could potentially send Alice another certificate signed with the same known CA. This is possible since the person performing the attack can have legally purchased a certificate from the CA. To prevent the man-in-the-middle attack, Alice must ensure that the domain name "Bob", i.e., the server she connected to, matches the domain name found in the certificate. The domain name is part of Bob's identification and is embedded in the certificate. Alice can finally trust Bob if the domain name in the certificate matches "Bob".

In the above scenario, only Bob must provide his certificate credentials. This is the typical use case for browser-to-server communication. For example, when you navigate to your bank, you want to ensure the browser helps you verify that the bank's website is trusted and that it is not hijacked by someone attempting to spoof you. The bank's server, Bob, also requires that Alice identify herself, but this is typically done by logging into the site, not by using client SSL certificates for identification purposes.

How to Use SSL Certificates in Embedded Devices

Only servers must provide a certificate With the TLS (Transport Layer Security) protocol. However, in some cases, such as with Internet of Things (IoT) solutions, it may be necessary for the client to provide a certificate for mutual authentication. This helps ensure that only registered and certified devices can connect to the server. The TLS protocol does support mutual TLS (mTLS), but it is more commonly used in IoT solutions where there is no human interaction during the connection phase. For example, an AWS IoT Core instance may be set up with mutual TLS authentication to ensure secure communication between devices. If you're interested in learning more about mutual TLS authentication and how to implement it, be sure to check out our SharkSSL Embedded TLS Stack and our online interactive AWS IoT Core MQTT Example, which is implemented in Lua.


With our own SharkSSL TLS stack, a certificate is installed by calling SharkSsl_addCertificate(). The certificate will then be sent to the TLS client as part of the initial asymmetric TLS handshake. A TLS certificate can also be sent from a TLS client to a TLS server if the server requests client authentication.

A list of CA certificates, containing at least one certificate, can be installed by calling SharkSsl_setCAList(). The peer's certificate can then be validated by calling SharkSslCon_trusted(). All internally use the SharkSslCon_trusted() function included IoT protocols and examples.

IoT (M2M)

If you're designing IoT (Internet of Things) or M2M (Machine-to-Machine) solutions, it's often necessary to install the server and device infrastructure, including the necessary certificates. In these cases, it can be beneficial to create your own root certificate and act as your own Certificate Authority (CA). This makes it easier to manage the certificates and allows you to sign certificates for non-standard domain names, such as "localhost" or "target1". To help streamline this process, we offer a free PKI tool that simplifies the creation of a complete PKI for IoT solutions.

The Big Elephant in the Room: Embedded Web Servers

It is tempting to try and save time and effort by using a self-signed certificate or a certificate signed by a non-trusted CA when shipping products. However, this quick fix can create more problems in the long run. Users bypassing the browser's security warning cannot differentiate between a man-in-the-middle attack and a non-trusted server's certificate. This can lead to serious security vulnerabilities and put the user and the product at risk. For more information on why using a non-trusted certificate is a bad idea, be sure to check out our tutorial on hacking web server enabled products.

Unlike an IoT solution where you, as a developer, completely control the chain of trust, Embedded Web Servers tend to cause significant frustration with their lack of control. While it is possible to be your own CA and set up a complete chain of trust, it can be challenging to deploy the solution effectively. Your customers may have trouble installing your CA certificate on all browsers/computers/devices that will connect to the embedded web server(s), and the certificate signing process may need to be performed on-site since the name or IP address in the certificate must match the one being used by the browser. These challenges can make it tough to ensure secure communication with Embedded Web Servers.

Using Let's Encrypt for Automated Embedded Web Server Certificate Management

If you're looking to quickly secure web servers running on private networks with private IP addresses, the good news is that the Let's Encrypt service with the automated certificate protocol ACME makes it possible to obtain trusted certificates. SharkTrust is a free product that automates installing these trusted certificates on microcontrollers, making it easy to ensure secure communication with your web servers. For more information on using Let's Encrypt with private web servers, be sure to check out SharkTrust. Our Xedge development tool includes an easy-to-use graphical user interface for enabling automatic certificate installation. The following slideshow shows how to enable automatic certificate management using Xedge when installed on an ESP32 microcontroller.

Automatic certificate management using Xedge when installed on an ESP32 microcontroller

Beginner's Guide To Secure IoT

With the free SharkSSL IDE, you can learn how to set up PKI for embedded systems, including setting up TLS mutual authentication with cloud services such as AWS IoT Core. The IDE also includes SharkTrust and eXtended SharkTrust Let's Encrypt examples. See the Beginner's Guide To Embedded Systems and Secure IoT Communication tutorial for details.

IoT Security: Creating X.509 Chain of Trust

The following IoT M2M Security video provides a practical example to set up on your computer for learning purposes. The comprehensive video tutorial guides you through setting up secure and trusted communication.

The video shows how to create an Elliptic Curve Cryptography (ECC) certificate for the server, install the certificate on the server, and make the clients connecting to the server trust this certificate. The server in this video is installed on a private/personal computer on a private network for test purposes.

Related Articles:

Although this was a quick introduction to digital signatures, SSL certificates, and trust management, it should be sufficient for you to use this information as a base when working with certificates. For more information, see the following two articles on Wikipedia:

Complex Circuitry Got You Stumped?

Don't let networking, security, and device management hold you back! Let Real Time Logic help your business, development team, or customers save time and money by handling these complex tasks for you.

With a wealth of experience creating IoT solutions and embedded device interfaces, we're well-equipped to dramatically improve your products and how you build them. And if you prefer to tackle things on your own, check out our extensive list of embedded web server and IoT tutorials.

Whether you choose to work with us or take the DIY route, we're here to help you succeed. Let's team up and make your vision a reality!


OPC-UA Client & Server

An easy to use OPC UA stack that enables bridging of OPC-UA enabled industrial products with cloud services, IT, and HTML5 user interfaces.

Edge Controller

Edge Controller

Use our user programmable Edge-Controller as a tool to accelerate development of the next generation industrial edge products and to facilitate rapid IoT and IIoT development.

On-Premises IoT

On-Premises IoT Platform

Learn how to use the Barracuda App Server as your On-Premises IoT Foundation.

Embedded Web Server

Barracuda Embedded Web Server

The compact Web Server C library is included in the Barracuda App Server protocol suite but can also be used standalone.

WebSocket Server

Microcontroller Friendly

The tiny Minnow Server enables modern web server user interfaces to be used as the graphical front end for tiny microcontrollers. Make sure to check out the reference design and the Minnow Server design guide.

WebDAV Server

Network File System

Why use FTP when you can use your device as a secure network drive.

HTTP Client

Secure HTTP Client Library

PikeHTTP is a compact and secure HTTP client C library that greatly simplifies the design of HTTP/REST style apps in C or C++.

WebSocket Client

Microcontroller Friendly

The embedded WebSocket C library lets developers design tiny and secure IoT applications based on the WebSocket protocol.

SMTP Client

Secure Embedded SMTP Library

Send alarms and other notifications from any microcontroller powered product.

Crypto Library

RayCrypto C Library

The RayCrypto engine is an extremely small and fast embedded crypto library designed specifically for embedded resource-constrained devices.

Embedded PKI Service

Automatic SSL Certificate Management for Devices

Real Time Logic's SharkTrust™ service is an automatic Public Key Infrastructure (PKI) solution for products containing an Embedded Web Server.


Modbus TCP client

The Modbus client enables bridging of Modbus enabled industrial products with modern IoT devices and HTML5 powered HMIs.

Posted in Whitepapers