For context, check the intro post.

Summary: How to use Signed Certificates in an IoT supply chain. Without giving away your private keys to your subcontractor.

At the end of this post, you completed 90% of the end-to-end process.

You, as subcontractor Louisiana Branch, will generate and sign certificates for Things, on behalf of the conglomerate United States Manufacturing.

No private keys will be shared. The subcontractor can generate the certificates, one for each Thing.

We as Root CA will only allow devices on our cloud that have a valid certificate chain and are provisioned.

The validation part (the focus of this saga) is portable across cloud solutions.

Subcontractor Generates Thing Certificate

This is what the whole story was written for: generate a unique, valid key pair for each device we want to sell.

A key pair that can be validated by our Root public certificate.

A key pair that can be generated by any subcontractor we have an agreement (trust contract) with.

Without sharing our private key and associated password to anyone.

Traceable end to end.

Create a Key Pair for the Thing

I've consistently used Certificate and Private Key in the series. But we're at the end, time to loosen up.

A certificate is the same as a public key. A certificate + private key is a key pair.

Key pairs are used to authenticate. Let's make one for the Thing that will be installed in New Orleans, LA.

In this post you will see that I have a code in front of the thing's unique name neworleans.

That is IoTConnect.io specific. The unique name is formed by the CPID (a code you get when enrolling, I obfuscated mine), and the unique name you define for your device. Separated by a '-'.

You are now pretending you are the subcontractor.

Create a key

This key does not have a password associated to it.

openssl genrsa \
      -out louisiana/private/b***2-neworleans.key.pem 2048
chmod 400 louisiana/private/b***2-neworleans.key.pem

Create a certificate

First the request.

The Common name has to be the unique name of the Thing on the Cloud:

CN: b***2-neworleans

openssl req -config louisiana/openssl.cnf \
      -key louisiana/private/b***2-neworleans.key.pem \
      -new -sha256 -out louisiana/csr/b***2-neworleans.csr.pem

Then the certificate, signed by the Intermediate CA private key (subcontractor's key).

openssl ca -config louisiana/openssl.cnf \
      -extensions usr_cert -days 375 -notext -md sha256 \
      -in louisiana/csr/b***2-neworleans.csr.pem \
      -out louisiana/certs/b***2-neworleans.cert.pem
chmod 444 louisiana/certs/b***2-neworleans.cert.pem

Verify the certificate

cat louisiana/index.txt

openssl x509 -noout -text \
      -in louisiana/certs/b***2-neworleans.cert.pem

openssl verify -CAfile louisiana/certs/ca-chain.cert.pem \
      louisiana/certs/b***2-neworleans.cert.pem

Create Full Certification Chain File

cat \
      louisiana/certs/b***2-neworleans.cert.pem \
      louisiana/certs/ca-chain.cert.pem \
      > louisiana/certs/b***2-neworleans-chain.cert.pem
chmod 444 louisiana/certs/b***2-neworleans-chain.cert.pem

The subcontractor has everything needed now for a successful connection:

• device public certificate chain: b***2-neworleans.cert.pem
• device private key: b***2-neworleans.key.pem
• Root CA certificate ca.cert.pem

What Have You Achieved: 90%

Previous posts:

You generated and installed a root certificate on IoTConnect Cloud.

You built a major part of the infrastructure that you will later use to generate the intermediate certificates.

Subcontractor generated a private key and a certificate request. They gave you the request file.

You generated the intermediate CA certificate and signed it with your Root CA private key.

You gave the certificate, your own root certificate, and the chain up to that point, to the supplier.

This post:

Subcontractor generated and collects all artifacts needed to authenticate a unique device for you.

Next article: Test! With a Node-RED flow. On a Raspberry Pi style device.