How to act as a Certificate Authority (the Easy Way)

Certificate (PKI) Management Tool

Are you concerned with recurring digital certificates fees or are you looking for a simple way to mass produce certificates for your embedded or IoT devices? This tutorial explains how to easily setup your own certificate authority by using a free tool we have developed!

The free certificate utility is an indispensable tool for administrators and a must-have for anyone that uses SSL Certificates for websites, servers, secure IoT device management, or Code Signing Certificates for trusted software.

As a provider of the World’s Smallest and Best-Performing SSL/TLS stack, Real Time Logic created this tool to specifically target our customer's pain points and make certificate management an easy task.

If you are a device manufacturer, you should also check out the article: Why You Need Automatic Certificate Management for Embedded Web Servers.

Certificate Management Tool

Download Ver. 5

See end of article for non Windows download options.


An introduction to this tutorial can be found at DZone.

The first questions you may ask yourself are:

  1. What does it mean to become a Certificate Authority?
  2. Why should you be your own Certificate Authority?

Becoming a Certificate Authority (CA) simply means that you are in charge of the issuing process of cryptographic pairs of private keys and public certificates, yet the process is automatically managed by our free tool. With that said, ANYONE can literally become their own Certificate Authority! Any entity or individual that endeavors to issue Digital Certificates for secure communications can potentially become their own CA and there are no implied restrictions or authorizations necessary to the contrary.

Most information readily available on the internet leans toward some sort of guidance on how to purchase and install certificates from retail based Certificate Authority, but there is very little reference for how to easily set up a CA structure.

The commercial Certificate Authority providers have (established) root certificates which are commonly found within everyday desktop browsers and consumer handheld devices, such as a mobile phone or tablet. For these types of devices, it make things easy to manage because pre-existing root certificates are commonly deployed in many consumer facing devices and easily auto-recognizable.

No one wants to spend extra time considering if every website visitation is legitimate or not, so the benefit of working with commercial Certificates is the established and existing chain of trust. Your desktop browser trusts the Certificate Authority and, therefore, your browser trusts the website.

Becoming your own CA requires that you install your public root certificate into browsers and devices that you plan on using with your server(s) before these browsers and devices can trust certificates signed by you.

Since embedded devices are typically designed by companies setting up the complete infrastructure, they have no need for or value in the utilization of pre-existing root certificates. These devices typically operate in closed environments where the same public infrastructure level of trust chain is simply overkill.  As an example, your home thermostat, has no need to search for a cooking recipe, or check stock prices..., however, within an Internet of Things (IoT) environment, the thermostat may need to maintain a secure connection to the cloud for remote monitoring and temperature adjustment.

Benefits of becoming your own Certificate Authority

  • Saving the expense of purchasing SSL commercial certificates from a Retail Certificate Authority for each embedded device which could potentially be a huge cost savings.
  • You have more control in defining access levels that are maintained at your own specified trust level.
  • Private issued CA Certificates create a much stronger security barrier than utilizing general 3rd Party retail certificates that are created for general use.

Consider that when 3rd Party CA certificate are compromised, ALL of the certificates you own that are signed by this Certificate Authority provider will also be compromised and must be re-issued. By acting as your own Certificate Authority all of these problems are avoided and left within the safety of your own control.

The below tutorial illustrates, without the need for any cryptic command line tools, how easy it is to set up and become your own Certificate Authority. Here we utilize the free tool we developed to simplify the process.

Free Certificate Authority Management Application (tool)


Although not required, it's good to have an understanding of Public Key Infrastructure (PKI) when using our free certificate management app. Check out our Certificate Management Tutorial if you want to get a better grasp on how PKI works.

The Certificate Management Application is a small web app that you download and run on your own computer. The app is currently available for Windows. See the end of the article if you are using another operating system such as Linux.

  1. Download the Certificate Management Application installer
  2. Start the installer and follow the instructions

The installer is a self extracting archive that extracts the necessary files and starts the web application on your computer.

Creating the Certificate Authority (CA) root certificate and private key

When you initially run the application, you will be asked to create the CA's certificate and private key. You can select a traditional RSA certificate or an Elliptic Curve certificate.


Elliptic Curve Cryptography (ECC) is a new technology and ECC certificates are much smaller than RSA certificates so you should select ECC if you plan on using the certificates in memory constrained devices or  setting up the certificate for a server that will communicate with memory constrained devices. A 224 bits ECC certificate is equally as strong as a 2048 bits RSA certificate. You should note that since ECC is a new technology, not all devices are able to process these new certificates. Our SharkSSL SSL/TLS stack is able to process both.

Selecting either RSA or ECC root certificates dictates how you create and sign certificates later on. Our Certificate Management Application, by design, does not let you create an ECC CA certificate and use this to sign an RSA certificate or vise versa. The complete chain will either be ECC or RSA.


The next step is to fill out the form for creating the CA certificate. Move your mouse over the help buttons for details about each field in the form.

Notice how we use "Real Time Logic Root Certificate" in the Common Name field. This field should have the domain name when creating and signing regular certificates, but the root CA certificate will not be used as a regular certificate so we use a more descriptive message in this field for the CA certificate.

You can create and sign certificates as soon as you have created the CA certificate and the CA's private key, but before doing so, install the CA certificate in your browser's and/or Windows' certificate store. The page you will see in your browser after clicking the "Create Key and Certificate" as shown in the figure to the left lets you download the CA certificate, which can then be installed. Your browser will not trust the certificates signed with your own CA certificate if it cannot find the CA certificate in its certificate store.

Creating, signing, and testing your first certificate

Click on the "Create Certificate" menu as soon as you have created the CA certificate and installed the CA root certificate as explained above. The form you fill in for creating and signing a certificate is the same form you used for creating your CA certificate. The difference is that the certificate you create now will be signed by using your root certificate.


For the following test, use the name "localhost" as the Common Name for your first certificate. You can use any name when creating and signing your own certificates, but the name localhost is the name of your local computer, that is, it is the address you type into a browser when accessing a server installed on the same computer.

Once you have created your first certificate, click on the Certificate Database (DB) menu. This page lists all the certificates you have created. When you move your mouse over a certificate, detailed information about the certificate is shown in a separate window as shown in the figure below.


To test the certificate, click on the certificate name. In our example, click "localhost". The page appearing after clicking on the certificate runs a script on the server and this script installs the certificate into a server listening object.


By clicking the URL on this page, you will be able to test your certificate. A new browser window opens and the browser should show a padlock to indicate that it trusts the certificate.


The above figure shows the Chrome browser trusting our certificate for "localhost". The figure also shows the certificate chain. You get to the certificate information dialog window in Chrome as follows: click the padlock, click "Connections", and then click "Certificate Information".

The cipher information shown on the page "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" shows that we use RSA and not ECC certificates, but that we use Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)key exchange algorithm. Although the certificate is an RSA certificate, the browser and the server agreed on using Elliptic Curve key exchange for the asymmetric encryption. Modern browsers favors ECDHE over plain RSA key exchange since ECDHE provides perfect forward secrecy (PFS). PFS makes sure that an observer recording the complete session will not be able to find the keys for the symmetric encryption AES should your private key at some time in the future be compromised.

Certificate Database Location

A certificate database is created for each CA certificate created. The databases are stored in the $HOME/.certmgr-db/ directory. For each CA certificate created, a subdirectory is created in .certmgr-db. These subdirectories contain the files associated with each CA database.

Each CA database directory contains the following:

  • ca.pem - the public Certificate Authority (CA) root certificate. This certificate must be installed by all clients connecting to servers signed with the CA certificate.
  • private - generated data that should be kept private, including the CA private key (ca.key).
  • keys-and-certs - All certificates created and signed with the CA certificate, including the certificates private key.
  • tmp - temporary data, including CSRs. A CSR is created during certificate creation. You may use the CSR if you wish to sign the created certificate using a well known certificate authority.

The Certificate Management Tool is internally using the OpenSSL command line tool for creating and managing the certificate databases. You may manage the databases using the command line tool if you are an OpenSSL expert.

To completely remove a database, simply delete the associated subdirectory in $HOME/.certmgr-db/

Creating, signing, and testing any certificate

You can create any number of certificates by using the procedures explained above. However, in order to quickly test a certificate with a name other than "localhost", a local DNS entry must be made in your hosts file. For example, say you create two certificates with the Common Names and MyHomeFridge. Clicking the link for these two hostnames on the certificate test page requires that you have added the two following entries to your hosts file: MyHomeFridge

Further reading:

IoT Security: Creating X.509 Chain of Trust

The Certificate Manager can also be used for creating certificates for an IoT solution. The following IoT Security video provides a practical example that you can follow and setup on your own computer for learning purposes. The comprehensive video tutorial guides you through the process of setting up secure and trusted communication.

The video shows how to create an Elliptic Curve Cryptography (ECC) certificate for the server, how to install the certificate in the server, and how to 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.

Running the certificate management app on non Windows computers

The certificate management app is included in the Mako Server tutorials. Download the Mako Server and use the included script to download the tutorials. After starting the Mako Server, navigate to http://localhost:portno/certmgr/

Posted in Whitepapers by bd