AVNET's iotconnect.io cloud platform is an online service that you can use to send data to, and then show it on a dashboard. In this blog series I'm learning how to talk to it with Node-RED. In this post: authentication with a CA generated certificate.
This is a better step forward in the safety than the previous post, where we let the IoTConnect portal generate a self signed certificate. If you have proper key and certificate management processes, this is production class security.
This post has useful information about certificates. What is a Certification Authority Root certificate? How to generate it. How to generate client certificates. Building a chain of trust. This is a practical implementation of a methodology that's used a lot. You can see it in operation here. And test it yourself at no cost. |
What is a certification authority (CA)? It's an organisation that can generate certificates. All certificates generated by that body can be traced back to it, and are validated by the CA's certificate. In this article, you are the certification authority for your own certificates. You will generate the certificates and keys for your IoT devices. Microsoft has a good explanation for using X.509 certificates in an IoT setting. |
Create Root CA and Prove that You Control It
Like most "non-browser" solutions these days that support certificate authorisation, you can be your own certification authority on IoTConnect.io.
The only requirement is that the server you are talking to recognises your root certificate as a Certification Authority (CA).
And you have to prove that. You will have to show IotConnect that you are the owner of the root certificate and its private key.
You can also use certificates you purchase for from a known certification authority. It does not add security, it adds trust. In this case, it's you trusting yourself, so the value of using an external certification authority is not that big. The story is different in other types of scenarios, where others have to trust you. In that case a certificate from one of the settled providers is an asset. |
Generate the root CA certificate
This can be done on any device that has openSSL installed.
There is other software that can do this too. If you use another certification generator, post a blog with instructions for it.
mkdir ~/.iotconnect cd ~/.iotconnect mkdir .CA cd .CA openssl genrsa -des3 -out CA.key 2048 openssl req -x509 -new -nodes -key CA.key -sha256 -days 1825 -out CA.pem
I entered these attributes. None of them play a role in the certification chain. They are for identification:
Country Name (2 letter code) [AU]:BE State or Province Name (full name) [Some-State]:Brussels Capital District Locality Name (eg, city) []:Schaarbeek Organization Name (eg, company) [Internet Widgits Pty Ltd]:e14 review with certificates Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:e14 review with certificates Email Address []:smartedge.element14@gmail.com
You need to provide a password. Take care to remember it. You 'll need it every time you generate certificates from this Certification Authority Root Certificate.
It's good practice to not share the password, nor the private keys generated in the activity here. Or in any activity you do with certificates. Make a habit of that.
Later in the process, whenever the command line asks to provide pass phrase for CA.key, this is the password you need to provide.
Load the CA root certificate to the IotConnect portal
The CA certificate will be used as a basis of trust by the IotConnect.io cloud services.
Any device that has a client certificate generated with this root certificate (and additionally is registered on IoTConnect and linked to this root certificate via its IotCOnnect Template) will be allowed to exchange data.
The certificate isn't trusted as a CA root when you upload it. It's merely stored.
More on the trust part later. Let's upload it first.
The not yet trusted certificate is on the server. I have to prove to the server that I have the password for this certificate (i.e.: it's mine).
You see that the status is "Pending":
Proof of Ownership
When I uploaded the CA root, the IoTConnect portal gave a challenge: a Verification code.
We need to show the service that we're able to generate a certificate from the CA root, where the certificate's common name (CN) is that verification code.
That's an exercise you can only complete if you have the CA root's password. I.e.: you own that certificate.
Let's generate that verification certificate. First the request:
openssl genrsa -out verify_ca.key 2048 openssl req -new -key verify_ca.key -out verify_ca.csr
This is a one-off certificate. Once the CA root is verified you can discard this.
You can neglect a number of parameters.
1589D3F9E31E82E3BA9B1CF78CD1F0DEC6A6FDEC736EB40C is the challenge verification code in my case.
You will get a different one when you upload your CA root certificate.
Country Name (2 letter code) [AU]:. State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:. Organization Name (eg, company) [Internet Widgits Pty Ltd]:. Organizational Unit Name (eg, section) []:. Common Name (e.g. server FQDN or YOUR name) []:1589D3F9E31E82E3BA9B1CF78CD1F0DEC6A6FDEC736EB40C Email Address []:smartedge.element14@gmail.com
Then use the CA root to generate the verification cerificate:
openssl x509 -req -in verify_ca.csr -CA CA.pem -CAkey CA.key -CAcreateserial -out verify_ca.crt -days 360 openssl x509 -in verify_ca.crt -out verify_ca.pem -outform PEM
Once generated, use it to verify the CA root on the portal:
Click the upload button at the right side of the table, select the verification certificate, then press Verify.
This is a first milestone. You are now a trusted certification authority for your organisation in IoTConnect.io.
All certificates you'll generate from now on will be trusted. Until the CA root certificate expires 
.
Create a Template for CA authorised Devices, and a Device
You define the behaviour of a set of devices on IotConnect with a template.
One of its attributes is the way of authorisation.
Template
Let's create one for CA authorised devices:
Save, then create at least one attribute.
I'm staying consistent with the blog series and create a Temperature.
I try to explain all steps in my posts. But this one we've seen several times now. Please read the previous posts if this attribute declaration is a mistery.
Save again.
Device
Now register the Thing.
It uses the template that's just created. That means it will authenticate via certificate I'll generate, and can exchange Temperature.
Create a Client Certificate
Now it's time to create the client certificate and private key.
Both will be used by the Node-RED IotConnect node to log on, together with the original CA root certificate.
First the request:
openssl genrsa -out client.key 2048 openssl req -new -key client.key -out client.csr
Feel free to provide or skip a number of attributes. The Common Name has to be <CPID-UniqueID>.
The unique ID is the one you just used when registering the device.
Your CPID (company ID) is available on the portal's Vault menu.
Country Name (2 letter code) [AU]:. State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:. Organization Name (eg, company) [Internet Widgits Pty Ltd]:. Organizational Unit Name (eg, section) []:. Common Name (e.g. server FQDN or YOUR name) []:<CPID>-e14noderedca Email Address []:smartedge.element14@gmail.com
You'll do this regularly if you have a device farm. It's a good idea to script this.
Use the CA to generate the certificate from the request:
openssl x509 -req -in client.csr -CA CA.pem -CAkey CA.key -CAcreateserial -out client.crt -days 360 openssl x509 -in client.crt -out client.pem -outform PEM
All done now. You've generated a private key and a certificate for your thing.
Configure Node-RED and Test
The last activity is to use this for real.
First upload the certificates to your device that's running Node-RED:
Client key: client.key
Client certificate: client.pem
CA root certificate: CA.pem
You can use a copy of the Node-RED Self-Service flow from the previous post to perform the test.
Just replace the UniqueID references in the Injection and IotConnect nodes with the one of the device you just created.
Point the x.509 attributes to the 3 files you copied over to the device:
Refer to this post for the correct ACK handling.
Deploy.
The IotConnect node should show a green flag.
Inject a payload, then go look at the IotConnect.io portal:
It works.
