Certificate Creation Guide

How /IOTCONNECT™ handles device certificates — understanding CA Certificates, Self-Signed Certificates, the creation workflow, what gets stored on the device, and how private keys are managed. This guide is designed for users setting up device authentication for the first time.

How Device Authentication Works

Every device connecting to /IOTCONNECT™ must prove its identity. This is done through X.509 certificates — a cryptographic system where each device holds a unique certificate and private key pair.

The authentication flow:

Device has: A certificate (public, proves identity) + a private key (secret, never leaves the device)

Cloud has: The CA certificate that signed the device certificate (trusts any certificate signed by this CA)

Connection: Device presents its certificate → Cloud verifies it was signed by a trusted CA → Connection established via mutual TLS

Two approaches in /IOTCONNECT™:

Method	What It Means	Best For
Self-Signed (Auto-generated)	/IOTCONNECT™ generates the certificate and private key for you	Quick start, prototyping, small deployments
CA Certificate (Bring Your Own)	You upload your own Certificate Authority; devices use certs signed by your CA	Production, enterprise, fleet provisioning at scale

Self-Signed Certificates (Auto-generated)

This is the simplest approach — /IOTCONNECT™ generates everything for you when you create a device.

What happens when you create a device:

Step 1: You create a device in the portal (Devices → Create Device)

Step 2: /IOTCONNECT™ generates a unique X.509 certificate + private key pair for this device

Step 3: The certificate is registered with the cloud IoT broker and attached to the device’s Thing/identity

Step 4: You download the certificate package (zip file containing .pem.crt and .pem.key files)

Step 5: You copy these files to the physical device

Step 6: The device uses these files to authenticate when connecting via MQTT over TLS

What’s in the downloaded zip:

File	What It Is	Security Level
`device-id.pem.crt`	The device’s public certificate — proves the device’s identity	Semi-public (safe to transmit)
`device-id.pem.key`	The private key — used by the device to prove it owns the certificate	SECRET — must never leave the device
`root-CA.pem`	The root Certificate Authority certificate — device uses this to verify the cloud server’s identity	Public (same for all devices)

On the device: Your SDK or firmware reads these files at boot, establishes a TLS connection to the MQTT broker, and presents the certificate during the TLS handshake. The broker verifies the certificate was issued by a trusted authority and allows the connection.

CA Certificate (Bring Your Own)

For production deployments, you can upload your own Certificate Authority (CA) and use it to sign device certificates yourself. This allows provisioning devices at scale without downloading individual certificates from the portal.

Workflow:

Step 1: Generate your own CA certificate (root or intermediate) using OpenSSL or your PKI system

Step 2: Upload the CA certificate (.pem) to /IOTCONNECT™ → Devices → Certificates → Upload CA

Step 3: /IOTCONNECT™ verifies the CA by issuing a verification code. You sign this code with your CA private key to prove ownership

Step 4: Once verified, any device certificate signed by your CA is trusted by the platform

Step 5: When creating devices, select your CA certificate instead of auto-generated

Step 6: Generate device certificates locally (signed by your CA) and install them on devices during manufacturing

CA Verification Process:

Upload CA → Portal provides a verification code (random string)

You create a verification certificate with the code as the Common Name (CN), signed by your CA’s private key

Upload the verification certificate → Platform confirms you control the CA

CA status changes to Verified — ready to use for device provisioning

When to use CA Certificates:

Manufacturing lines where certificates are provisioned during device production

Fleet deployments of 100+ devices where individual certificate downloads are impractical

Organizations with existing PKI infrastructure

Compliance requirements mandating specific certificate properties or key sizes

Private Key — What You Need to Know

The private key is the most critical security element in device authentication. Understanding how it works prevents common mistakes:

Question	Answer
Where is the private key stored?	Only on the physical device. /IOTCONNECT™ does NOT retain a copy after generation.
Can I download it again?	No. The private key is available ONLY in the initial download. If lost, delete the device and create a new one.
Should I email it?	NEVER. Transfer only via secure channels (SCP, USB in a secure facility, encrypted archive).
What file permissions?	chmod 600 (owner read-only). No other users or processes should be able to read it.
What happens if compromised?	Delete the device immediately from /IOTCONNECT™. This revokes the certificate instantly.
Can multiple devices share a key?	NEVER. Each device must have its own unique certificate + key pair.
Does the key expire?	The certificate has a validity period. The key itself doesn’t expire but becomes useless when the cert expires.

Certificate Requirements

Requirements for certificates used with /IOTCONNECT™:

Requirement	Value
Format	PEM (Base64 encoded, .pem or .crt extension)
Key Algorithm	RSA 2048-bit or higher (recommended: RSA 2048 or ECDSA P-256)
Signature Algorithm	SHA-256 or higher
CA Certificate	Must include Basic Constraints: CA=TRUE
Device Certificate	Common Name (CN) should match the device Unique ID
Validity Period	Recommended: 1-5 years for device certs, 10-25 years for CA certs
Max CA Certificates	Up to 25 per account (platform limit)

Common Mistakes

Mistake	What Happens	Solution
Lost the private key	Cannot connect the device — key is irrecoverable	Delete device, create new one, download fresh certificates
Using same cert for multiple devices	Only one device can connect at a time (duplicate client ID disconnects)	Generate unique certificate per device
Certificate expired	TLS handshake fails, device cannot connect	Re-provision device with new certificate before expiry
Wrong Root CA on device	Device cannot verify server identity	Use the Root CA file from the downloaded zip — not a generic one
Clock not set on device	Certificate “not yet valid” or “expired” errors	Enable NTP or manually set correct date/time before connecting
File permissions too open	Security risk — other processes can read the private key	Set chmod 600 on the .key file

ⓘ QUICK REFERENCE

For quick prototyping: Use Self-Signed (auto-generated) — just create the device and download the zip.
For production: Upload your own CA → sign device certs in your factory → install during manufacturing.
If something goes wrong: Delete the device from portal (revokes certificate immediately) → create fresh → download new certs.