The shortest path should be the most secure
We’re not building games at Golioth, but today we are borrowing an idea from the gaming industry: the most optimal way of playing a game should also be the most fun. Players are always going to pick the shortest path to winning the game, so it’s the game developer’s job to make sure this path also makes the game as fun as possible. Extending this idea to IoT and building more secure products, a corollary would be: The shortest path to shipping products should also be the most secure.
The Problem
Currently, we support two types of credentials on the Golioth Cloud: Pre-Shared Keys (PSKs) and Certificates. When starting a new project on Golioth, one of the first things our users do is add their device in the Golioth Console, and set up some credentials that lets their device authenticate to the cloud. This is really creating a cloud-side representation of the device, which has yet to connect to the platform.
PSKs are easy to understand and easy to use, being similar to a username/password. But they’re less secure than certificates: PSKs have to be stored on both the device and in Golioth’s servers ahead of time, which increases the overhead to the manufacturing entity, as well as the number of attack vectors.
Certificates only include the public part of the device’s encryption key, and Golioth does not need to know the contents of the device’s key to verify its identity. We want to encourage our users to use certificates for authentication, but unfortunately, generating and signing certificates is pretty cumbersome, especially in the early stages of development.
Ideally, developers should be setting up their own Public Key Infrastructure with an external provider, but this can be both intimidating and time consuming. We made a short guide showing how they can sign their own certificates, but that’s still not a production-grade solution. Storing your own private key for a root CA is much less secure than a Public Key Infrastructure provider. But, again, this is done to allows users to bypass the cumbersome PKI setup process during their initial setup.
The difficulty again ramps up for users looking to just try out the capabilities of something like Golioth Connectivity: generating and loading self-signed certs is still harder than just copying the PSK onto the device. As a result, a lot of our users end up using PSKs during their development phase. When they’re ready to take their product to production, they often continue using PSKs (why rock the boat, right?). We’ve effectively failed them: The shortest path to shipping their product was with the less secure authentication method, so that’s what they chose.
Introducing The Certificate Generator
What if we could maximize security and convenience? To reduce the threshold for getting started with certificate based authentication, we have added a Certificate Generator to the Golioth Console.

The Certificate Generator allows you to generate certificates and private keys for your devices directly in your browser, making it easy to use certificate based authentication throughout your development process. You don’t have to install any command line tools, and you can easily transition to an external Public Key Infrastructure provider later, without changing your firmware.
You can find the Certificate Generator from the Certificates page in the console, or at the end of the device creation workflow. Note that you do not have to create the device before generating the certificate. Through Zero Touch Provisioning, you can just set a unique device name in the generator, and the device will get created in Golioth as soon as it authenticates.
The Certificate Generator creates a temporary certificate authority that gets used to sign a device certificate you can download, alongside a matching private key. The certificate authority gets registered with Golioth automatically, and the certificate signing key is discarded as soon as it has signed the device certificate. Golioth never stores or even sees any of your generated private keys, so if you lose it, you’ll need to generate a new one.
You can run the Certificate Generator as many times as you’d like, and each device certificate you generate will have its own dedicated certificate authority registered with Golioth. You can invalidate the device certificate by removing its certificate authority (sometimes referred to in our docs as a ‘root ca’).
Limitations
The goal of the Certificate Generator is to make it easier to pick the strongest authentication method for your product, but we have to be careful to avoid weakening the security in the process. To ensure that the certificate generator doesn’t get abused, we’ve added some restrictions:
- Generated certificates and their corresponding certificate authorities are only valid for four weeks. Once your certificate expires, you’ll have to generate a new one, or change to a proper Private Key Infrastructure provider.
- As the certificate signing key gets discarded right away, it can only be used to sign a single device certificate.
- Certificate authorities registered by the Certificate Generator get a
DEMOtag attached to them. This is visible in the console and management APIs, but it does not affect the certificate authority’s behavior as long as it’s valid.
We’re working on some pretty big improvements to the certificate based authentication workflow, which we’ll be able to show you pretty soon. We hope the Certificate Generator makes it easier to start using certificate based authentication from the very first device you connect to Golioth. Let us know what you think on our forums or reach out directly!


No comments yet! Start the discussion at forum.golioth.io