Certificate 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.
The first questions you may ask yourself are:
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
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.
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.
The installer is a self extracting archive that extracts the necessary files and starts the web application on your computer.
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.
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.
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 www.mycompany.com 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:
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.
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