When devices connect to a cloud service, they often receive a .crt or .pem file and configure it in a TLS, MQTT, or HTTPS client.
That makes it easy to think a device certificate is just a file. In reality, the certificate is only the visible piece of a trust chain. The real design questions are: how does the device prove who it is, how does the server verify that identity, how is the private key generated and protected, and what happens when the certificate expires or the key leaks.
A typical device certificate chain looks like:
Root CA
-> Intermediate CA
-> Device Certificate
-> Device Private Key
The server trusts the Root CA or an intermediate CA. During connection setup, the device sends its device certificate and any required intermediate certificates. The server validates the chain, validity period, usage, and device identity fields, then verifies that the device holds the private key corresponding to the public key in the certificate.
Certificate chains solve how identity is trustfully bound to a public key. They are not merely a file format.
A Certificate Binds Identity to a Public Key
The core contents of a certificate are:
subject / SAN / device identity
public key
issuer
validity
key usage / extended key usage
signature
A CA signs these contents with its private key. A verifier uses the CA public key to confirm that this public key and identity claim were issued by a trusted CA.
A device certificate often represents:
- device serial number
- device ID
- product model
- tenant or project ownership
- device public key
- certificate validity period
- intended device authentication usage
The important part is not what the fields look like. The server must know exactly which field contains the device identity, and that field must be covered by the certificate signature.
Modern TLS deployments should not rely on CN as the primary identity field. SAN is more common, or a private PKI can explicitly define how device identity is encoded in subject, SAN URI, SAN DNS, or SAN otherName.
The Private Key Is the Root of Device Identity
A certificate is public material. It can be sent to the server and can be seen by others. Leaking the certificate alone usually does not mean the device can be impersonated.
The sensitive part is the device private key.
When a device proves its identity, it is essentially proving:
I hold the private key for the public key in this certificate
So the security boundary of a device certificate system depends on private-key protection:
- whether the private key is generated on the device
- whether the private key ever leaves the device
- whether it is stored in plaintext flash
- whether debug ports can read it
- whether firmware logs print keys or credential bundles
- whether provisioning tools store private keys in bulk
- whether factory reset accidentally reuses or overwrites keys
If all devices share one private key and one certificate, one compromised device affects the whole fleet. Device identity should generally be one certificate and one private key per device.
Root CA, Intermediate CA, and Device Certificates Have Different Jobs
Root CA is the trust anchor. It is usually long-lived, managed offline, and used sparingly.
Intermediate CA signs device certificates. It can be split by product line, region, customer, manufacturing line, or batch.
Device Certificate is the identity credential deployed to one device.
Root CA: trust anchor, long lifetime, strong protection
Intermediate: signs device certificates, can be scoped
Device Cert: per-device identity, deployed with the device
Device Key: per-device private key, must not leak
This layering isolates risk. A problem in one manufacturing line’s intermediate CA should not immediately affect every product line. A leaked device certificate should not affect other devices.
Do not put the Root CA private key into provisioning scripts, build machines, or ordinary cloud services. Once the Root CA private key leaks, the trust system may need to be rebuilt.
Chain Validation Is More Than Signature Verification
Validating a device certificate is not just checking whether a signature verifies.
At minimum, check:
- whether the chain reaches a trusted CA
- whether every certificate is within its validity period
- whether CA certificates actually have CA permission
- whether the device certificate usage permits client authentication
- whether signature algorithms and key sizes meet policy
- whether the device identity field matches business records
- whether the certificate is revoked or disabled
- whether host name or device ID matches the expected identity
In mTLS, after the server validates the client certificate, it still needs to map the certificate identity to a business device record:
certificate SAN / subject
-> device_id
-> product / tenant / policy
-> authorization
TLS performs cryptographic authentication. Whether the device can access a topic, API, or resource belongs to the authorization layer.
Time Matters to Certificate Systems
Certificates have notBefore and notAfter fields. The verifier needs reliable time to decide whether a certificate is currently valid.
Servers usually have reliable time. Device-side validation of server certificates is harder:
- the device may not have an RTC
- the RTC battery may be dead
- NTP may not be available at boot
- factory time may be a default value
- offline environments may not provide time sync
Wrong device time can cause two classes of problems:
- a valid certificate is rejected as not yet valid or expired
- an expired or replaced certificate is incorrectly accepted
Common engineering approaches include secure time sources, storing the last trusted time, delaying sensitive connections until time sync, or designing a controlled first-provisioning flow for time bootstrap.
Do not simply disable certificate time validation. That removes the meaning of certificate validity periods.
Revocation and Rotation Must Be Designed Early
Certificates expire, private keys leak, devices are repaired, and CAs may need replacement.
A certificate system must answer:
- how device certificates are renewed before expiry
- how devices are disabled after private-key leakage
- whether devices can trust a new chain during CA rotation
- how long-offline devices handle old certificates when they reconnect
- whether the server supports per-device certificate disablement
- whether CRL or OCSP fits the device environment
- whether a failed certificate update can brick the device
In IoT, traditional Web PKI revocation mechanisms may not apply directly. Devices may be offline for long periods, have constrained networks, or fail to reach OCSP reliably. Many systems maintain server-side device state, certificate fingerprints, serial-number deny lists, or device disable lists.
Rotation also cannot be left until “the certificate is about to expire”. Devices need a secure update path, servers need to accept old and new chains for a transition period, and provisioning and repair systems need to understand the new certificate policy.
Provisioning Is Part of Certificate Security
Device identity is often created or injected during manufacturing.
There are two common models.
First, the device generates the key pair:
device generates private key
-> exports public key / CSR
-> CA signs device certificate
-> device stores certificate
The benefit is that the private key never leaves the device. The challenge is a more complex provisioning flow and a device that has reliable RNG and CSR/signing integration.
Second, a provisioning system or HSM generates the key and certificate, then injects them into the device:
HSM / provisioning system generates key pair
-> CA signs certificate
-> injects private key + certificate into device
The benefit is controlled process flow. The challenge is that the private key passes through an injection path, so transport, workstations, logs, temporary files, and permissions must be protected.
Avoid:
- flashing the same certificate image to every device
- private keys appearing in CSV files, logs, screenshots, or reports
- workstations keeping plaintext private keys long term
- serial numbers not matching certificate identities
- failed provisioning leaving devices in a half-identity state
- repaired devices getting new identities while old identities remain active
Provisioning is not outside the security system. It decides where device identity comes from.
Certificate Is Not Authorization
A device certificate proves that the holder of a private key matches some device identity. It does not automatically define what the device can do.
Authorization usually checks:
- which product the device belongs to
- which tenant owns it
- whether it is activated
- whether it is disabled
- whether it may access a topic
- whether it may receive OTA
- whether it may write configuration
Certificate identity should map to a server-side device record. Do not treat a valid certificate as all permissions.
mTLS authenticated device_id
-> lookup device record
-> check tenant/product/status
-> apply policy
This is why certificate field design must be stable. If fields are messy, authorization, auditing, revocation, and operations all become harder.
Debugging Order
For TLS failures, server-side certificate rejection, mixed device identities, expired certificates, or fleet-wide authentication issues, inspect:
does the device private key match the certificate public key
-> does the device send the required intermediate certificates
-> does the server trust the corresponding Root/Intermediate CA
-> are certificate validity period and system time correct
-> do key usage / extended key usage permit client authentication
-> does the device identity field match the server record
-> is the serial number or fingerprint disabled
-> does provisioning use one certificate and one private key per device
-> could the private key leak from flash, logs, debug ports, or workstations
-> is CA rotation deployed on both server and device sides
A device certificate chain is not just putting a PEM file in the right directory. It is an engineering system that connects device identity, public keys, private-key protection, CA trust, lifecycle, and manufacturing.