Creating a Self-Signed SSL Certificate for Secure IoT Applications

connection_not_secure
Share on facebook
Share on reddit
Share on twitter
Share on linkedin
Share on email
Share on print

These days, special consideration into the security of your internet accessible devices is a must. The proliferation of the Internet of Things (IoT) has provided a multitude of opportunities to hackers. Installing an SSL certificate on your IoT devices is a terrific way to protect your data and IoT from attack. Not all IoT needs to be secured but for systems that are accessible via internet, rather than just a local area network, it’s a good precaution for preventing data breaches and malware infections.

In our prior article “Cover Your Data Assets with SSL” you can get caught up on some important details about SSL / TLS and how to get it working for your NetBurner App.

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 site 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 web site 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”.

URL bar showing a secure HTTPS connection
URL bar showing a secure HTTPS connection

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 nburnconfig 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:

Making a certificate from the command prompt
Making a certificate from the command prompt

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:

Self signing the SSL certificate from the command line
Self signing the SSL certificate from the command line

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:

Browser warning you will see with self signed SSL certificates
Browser warning you will see with self signed SSL certificates

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:

Browser advanced setting and exceptions
Browser advanced setting and exceptions

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.

Adding a security exception
Adding a security exception

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.

Viewing the security certificate from your browser
Viewing the security certificate from your browser

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

Example of an SSL certificate as seen through browser
Example of an SSL certificate as seen through browser

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.

The browser certificate manager provides detailed information
The browser certificate manager provides detailed information

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:

Green pad lock indicating an SSL connection
Green pad lock indicating an SSL connection

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.

Share this post

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on email

Subscribe to our Newsletter

Get monthly updates from our Learn Blog with the latest in IoT and Embedded technology news, trends, tutorial and best practices. Or just opt in for product change notifications.

8 thoughts on “Creating a Self-Signed SSL Certificate for Secure IoT Applications

  1. Do I understand correctly that, if a company makes 100 identical widgets, that each widget will have to have its own build of the firmware so that they each have their own certificate? Or is there a way to load a certificate into an app after its been built?

    1. Thanks for the question! The application can be built to load certificates at runtime. There are several examples showing how to do exactly this with the NNDK.

  2. Google Chrome requires adding subject alternative names (SANs) to your Multi-Domain SSL Certificate. Could you show up how to do that?

    1. Hi There! That’s a good question. When we do this, we use a config file that is included with the -config flag when we run OpenSSL from the command line. This is done by adding the following to that config file:
      [usr_cert]
      ...
      subjectAltName = @alt_names

      [alt_names]
      IP.1 = // Replace with your IP addresses, or use DNS.# for domain names
      IP.2 =

      A more in depth explanation can be found here. Hope that helps!

  3. it’s a great tutorial thanks,
    i have an iot project based on esp8266 module, i want to secure esp8266 as sever web.
    but I do not know
    can I use this method in my server esp8266 and how can I use NetBurner can you explain me more?
    Thanks for your help

    1. Hi there! Thank you very much, we really appreciate hearing that. =)

      The certificate generation process outlined here would definitely work for any device (minus generating a .cpp that can be compiled into the application). The actual web server that is hosting the page and handling the secure connection is run off of a NetBurner device. While our modules could be used in conjunction with an ESP8266, the actual software running (including the test application, the RTOS, security libraries, and all of the drivers) are written specifically for NetBurner hardware. If you would like more information to see if there is a solution there that might work for your particular requirements, please feel to reach out to us. We are always happy to discuss potential projects, love hearing about what others are working on, and can help determine if our products would be a good fit or not.

      1. hi thanks for your answer,
        what i want to do is to monitor and control a device remotely using a web page hosted on esp8266 server.
        I wanted to encrypt the communication so that the data sent is not captured by anyone or less to be taken by malicious users

        1. Just doing a little digging, it looks like there is a SSL/TLS option for the ESP8266 with BearSSL. That said, due to the memory footprint of the module, it appears that the number of available concurrent connections at a given time is one. From what it sounds like, using a NetBurner device, such as the MODM7AE70 or the MOD54415, would essentially replace the ESP8266. The SSL/TLS library is part of our system code, and several examples are provided to get you started. Our modules are a little beefier than the ESP8266 in terms of processing power and memory, so the speed of negotiating a connection and the actual available number of concurrent connections would be higher. Unfortunately, they don’t natively support wireless, so you would need an additional module for Wifi support. It’s hard to say what the best path would be for you without a greater understanding of your project and requirements, but it sounds like you have several options available! Please don’t hesitate to contact us if we can answer any other questions for you.

Leave a Reply

Your email address will not be published. Required fields are marked *