Hi @meraj,

The NervesKey is really an ATECC608A. These chips are highly configurable so for Nerves, we decided on a setup that worked for our use cases of connecting to AWS IoT and NervesHub. There are two slots for keys and certificates: one slot is permanent and the other can be rewritten as much as you want (it’s called the aux slot for historical reasons). Everything is open-source, so you can modify it if you want, but my hope is that you don’t need to.

One thing to be aware of is that public key infrastructure is used more simply in practice with IoT services (I’m familiar with NervesHub and AWS IoT, but I’ve been told that others are similar).

So we’re using the same words: Devices have a public and private certificate. When using the ATECC608A, the private key in the private certificate is stored so that it never leaves the chip. The device’s public certificate is signed by another certificate generically called the signing certificate. This can be the CA certificate or an intermediate like in your case.

The crucial piece of information is that NervesHub, AWS IoT, and other services like that record device public certificates. That means that if a device is known to a service, ONLY the device’s public certificate needs to be valid to authenticate the device. That means that the signing certificate can be invalid and it won’t matter.

Of course, at some point in time you have to tell NervesHub or AWS IoT about your device. The server needs to know the signing certificate at this point. There are two ways of provisioning the server with new devices.

It can be done off the device. For example, if you make a lot of devices, you can write a script that records device certificates from the manufacturing line and upload them to the server. The certificates will need to be signed and the signing certificate needs to be valid for the server to accept the device certs.

The registration can also be done on the device. This is called JITP (just in time provisioning) on AWS and the idea is that the first time a device connects, the certificate chain will be validated and the device certificate registered. The downside to JITP is that if your device sits in a warehouse for a long time and the signing certificate’s expiration date passes, you’ll have to manually update the cert on the device for it to work.

The point is that there might be a way to avoid the 30 day re-signing of certificates.

Regarding your second question about SSH. If you have ssh running and the device is reachable, you’ll be able to get an IEx prompt. If your device is behind a firewall, then take a look at NervesHub. You have to enable IEx prompt access with NervesHub on your device, but if you do that, NervesHub will enable a button on the UI that will give you a shell window.

Hope this helps!