Creating a Self-Signed SSL/TLS Certificate for Secure IoT Applications

One can purchase an annual SSL certificate for each of your IoT devices but in many cases this expense is not justified. In this article, we’ll show you how to produce self-signed SSL certificates for all your NetBurner devices for free. We’ll also cover a few of the functional concepts behind public key cryptography using SSL certificates and their encryption and authentication capabilities.

Just want the tutorial and none of the discussion around SSL? Cut to the chase here.

How do SSL Certificates work?

To understand why an SSL certificate is important we will take a trip back in time to the 1990’s. The internet was brand new and Netscape browser decided to support commerce over the web. At the time regular HTTP web pages were delivered unencrypted over TCP, so anybody that had access to the network or router anywhere along the path could eavesdrop on the transferred data. This was problematic as credit card information and other private details could easily be intercepted. The solution was to encrypt the data so that no one could snoop on your information.

But there is a problem. If we have not communicated before with the e-commerce site (we’ll use Amazon.com for our example) how do we set up a secure connection so that both sides know the same key to encrypt and decrypt the data? And how do we know that we have truly reached the e-commerce server and not a malicious imposter hoping to skim our credit card information?

Enter the magic of public key cryptography or also known as asymmetrical cryptography. This technique requires that a secure website, like Amazon, have an SSL certificate which allows the site to use a unique public encryption key and a unique private encryption key. The website’s SSL certificate is usually provided by a 3rd party Certificate Authority (CA). The CA validates the legitimacy of the website and provides the unique public and private keys for use only with the specific website (the specific IP address or Domain Name).

When you connect to the Amazon server it gives your browser it’s unique public certificate containing its unique public key. The visitor’s browser can now use Amazon’s public key to encrypt all data (HTTPS requests), like credit card information. A public key has the property that you can encrypt information with the public key, and only the holder of the matching private key can decrypt it. So, what happens is that when you start the SSL connection your web browser picks a random number that will be used to generate a symmetric key for the connection. The browser then uses the public key sent by the Amazon server to encrypt that random number and send it to their server. Now both sides have the same “secret key” and can communicate without worrying about anyone snooping the wire. But, there is yet another flaw…

What happens if a bad guy sits between the web browser and Amazon and pretends to be Amazon? When your browser thinks it is connected to Amazon, it could be connecting to the bad guy instead. The bad guy then has access to all your information. This is the second problem that SSL set out to solve: verifying that you are connected to the website that you think you are visiting; especially, prior to sending sensitive information. Host authentication on behalf of the visitor is a major benefit and is a part of the certificate chain.

When Amazon sets up its web server it creates a public key and a private key. It then takes the public key and sends it to a third party, a Certificate A (CA). The CA takes the public key and creates a digitally signed certificate to certify that the Amazon public key is owned by Amazon and matches the name or IP address of www.amazon.com.

When your browser connects to Amazon is does several things. In respect to SSL certificates most importantly:

1. It checks to see if the certificate the server gave it matches the website name/address.
2. It checks to see if the certificate is signed by someone it trusts: a CA that is on the browser’s list of trusted authorities.

If both these tests pass, the browser uses the public key to send its secret to Amazon, and both sides use that secret to communicate. You will know this has succeeded if the URL bar on your browser shows the familiar green padlock secure symbol and/or the URL contains “HTTPS” instead of “HTTP”.

 

If instead of Amazon we end up unknowingly connected to the Bad Guy, one of the two tests will fail. In some cases, the Bad Guy might own an actual signed certificate, but the domain name or IP address do not match that of Amazon.com. Or, he provides a certificate that says it is Amazon, but it is signed by a CA that is not on your trust list. Either case will cause the connection to be aborted and your browser will display a security warning.

SSL Certificates for IoT and Embedded Applications

Let’s get back to your embedded IoT project and the most often asked question: I’m not trying to be Amazon, I just want security for my embedded device. Why do I need all this?

You need all this because the web browser does not know the difference between connecting to Amazon or your embedded device. It only has two modes of operation: secure or not secure (HTTPS vs HTTP, respectively). To be secure it needs to make sure that you are talking to the intended site and that you are not talking to a Bad Guy in the middle. This means it needs a certificate whose name matches the name in the URL box and that that certificate is signed by a CA the browser trusts. For the web browser to make a secure SSL connection to your embedded device it needs to pass the same two steps described above.

Question: Why can’t I use one certificate for all my devices, why must I have a different certificate for every single device?

You must do this because the certificate contains what is called the “Common Name”. For example, www.amazon.com. A common name can also be an IP address. The common name must match whatever you put into the browser’s URL box. If you put an IP address in the browser’s URL box, the certificate must then have a common name that matches. If you try to reuse one certificate it will fail because to talk to different devices, you must use different names or addresses and the common name in the certificate will not match.

Question: Okay, I see to pass step one above I need to have a certificate with a different common name for every device. What about part two, the Certificate Authority (CA) signature?

As long as the name on the certificate matches whatever you put in the URL box, and the certificate is signed by a CA that your browser trusts it will work. Typically for commercial websites, you would just purchase an annual certificate from a registered CA that is pre-loaded into every browser’s trust list. However, buying annual SSL certificates for each of your embedded devices can become quite expensive and a logistical certificate management nightmare. An alternative, is to become your own CA and sign your own certificates. There is just one minor down side. It’s very unlikely that MyOwnEmbeddedDevicesCA is on the list of CA’s the browser will accept.

So, when you create your own CA, “MyOwnEmbeddedDevicesCA” and sign certificates for your devices, the browser will still reject the certificates per test two above because your CA is not on its pre-loaded trusted CA list. Thus, for all browsers that that will connect to your Self Signed certificate, you must manually add “MyOwnEmbeddedDevicesCA” to the browser’s list of trusted CA’s. Otherwise your users will have to go to the browser’s “advanced” setting link and click through the all the warning messages.

DIY Self-Signed SSL Certificate and Certificate Authority

Your NetBurner development tool set contains the openssl utility and a few script files to make creating certificates quick and easy. We will explore these tools and also look behind the scenes at what these scripts are doing so you can change the options if you wish.
The script files for both Windows and OSX are located in the \nburn\config directory:

• makeca.bat, makeca.sh — Create a Certificate Authority certificate and key
• makeserver.bat, makeserver.sh — Create a certificate and key signed by the CA
• checkkey.bat — Display a key
• checkcert.bat — Display a certificate

These utilities are run from the command line, so start by opening a command prompt and go to the config directory where the files are located. The first step will be to make our Certificate Authority certificate. Run the makeca script and follow the prompts:

 

Looking at the output we can see that we first make a 1024-bit RSA private key named CA.key. Next, we create the CA certificate named CA.crt. The -days option sets the expiration for 10 years from the date it was created. The questions are pretty straight forward. Note that the Common Name is supposed to match the name or IP address of the CA.

Now we can make our server certificate and sign it with the CA certificate we just made:

 

Here again we are making a 1024-bit RSA private key named device.key. If you wanted a larger key, you can edit the script file and change it (e.g. 2048). Next, we create the certificate request named device.csr. We see the same set of questions as before. But this time you need to be very specific with the Common Name. The name must match exactly what you would type in to the URL field of your web browser. In this case we are not using a DNS server to resolve a name, so we enter in the device’s IP address. Note that if the device IP address changes the certificate will no longer be valid.

When the device.crt certificate is created you can see the options specify that the expiration is 10 years, and that it is signed using CA.crt and CA.key. There is also one additional step. nbsslconvert is used to generate a devicekey.cpp file. This can be used if you want to compile the key into your application.

We will now use the device certificate and the key we just generated in the NetBurner SSL Web Demo example program. The devicekey.cpp file was copied into the project, renamed to key.cpp (since that is the name the example uses); the project was then built, and the image downloaded into a MOD54417 core module. When go to the 10.1.1.68 website we are greeted with:

 

The reason for this is that the web browser has a trusted CA list, and our self-created NetBurner CA is not on it. If we click on the Advanced button we get a more detailed explanation and a button we can use to add an exception:

 

You can uncheck the Permanently store this exception if you just want to go to the site for testing purposes, then click the Confirm button.

 

You will now be able to view the example’s web page with SSL. If you look at the green lock symbol in the URL box you can see that it still has a warning. This is because our CA is still not in the trusted list.

 

If you click on the lock symbol for more information you can view the certificate:

 

If we use the web browser certificate manager to import our own CA to the trust list (CA.crt), the lock symbol will turn green and any other devices with certificates signed by NetBurner CA will be accepted.

 

After installing our CA to the trusted list of the browser, the lock symbol is now green and if we click on it for more information it will say the connection is secure:

 

We hope this was a useful post to help you on your way with securing your IoT assets. As always, leave a comment below to share or to ask questions.