Definition
X.509 Certificate (X.509 Certificate) is the standard certificate format in public key infrastructure (PKI), used for device identity authentication. Devices can use X.509 certificates instead of ProductKey/DeviceSecret for Device Authentication, combined with mTLS to achieve mutual authentication, suitable for high-security scenarios.
Certificate Structure and Lifecycle
An X.509 certificate contains subject information, a public key, issuer, validity period, extension fields, etc. Device certificates typically write the device's unique identifier (such as DeviceId or serial number) into the Subject or SAN extensions; the private key is securely stored in the device security element (SE) or TEE. The certificate lifecycle includes issuance, deployment, renewal, and revocation. The Device Management Platform can integrate a CA or connect to an enterprise PKI, supporting batch certificate issuance, automatic renewal, and CRL/OCSP revocation checks, meeting the compliance requirements of Device Credentials management.
Cooperation with mTLS
In mTLS mutual authentication, the device and the platform verify each other's certificates during the TLS handshake. The device uses a pre-installed root CA certificate to verify the platform's certificate, and the platform verifies the device certificate's signature chain and revocation status. Compared with pre-shared keys, certificate authentication supports fine-grained identity binding, non-repudiation, and key rotation, making it suitable for high-security IoT scenarios such as industrial control, finance, and healthcare. The platform needs to support one-to-one or one-to-many certificate-to-device binding policies.
Implementation Considerations
The device side needs to have certificate storage and TLS client capabilities; resource-constrained devices can consider certificate simplification or use Raw Public Key. The platform side needs to establish a complete process for certificate issuance, storage, and revocation, coordinated with strategies like One Device One Secret, ensuring that each device credential is unique and traceable. When a certificate expires or is revoked, the platform should support alerts and automatic disconnection to ensure overall security.
A certificate binds a device identity, not a session
A device certificate gives a public key and a set of identity fields to an issuer to sign. During the handshake the platform checks that signature chain, and so knows that the other end of the connection holds the matching private key. What it proves is the device identity, not that a particular business session has been authorized to do something. After the session is up, whether control may be sent, and which data may be seen, still needs a separate authorization. Treating "the certificate checked out" as "every service may be executed" gives operational rights to any connection that presents a valid certificate.
The identity should be written in the subject or the subject alternative name, and it should correspond one to one with the platform device identifier. One device, one certificate in use, is the easiest arrangement to audit. If the same certificate is copied onto several devices, revocation cannot stop only one of them. Renewal has to finish before the expiry date: issue the new certificate, confirm the device has stored it, then switch trust. Do not wait until after expiry, when the device can no longer come online, and only then reissue. Renewal is a credential rotation after provisioning. It should not ask the user to scan again. If a vehicle terminal or a field gateway holds identities for devices downstream, the model should say whether the certificate belongs to the terminal or to the downstream device. See an access point such as the T-Box. Do not treat a whole-vehicle certificate as the identity of every controller.
It suits a primary credential only when the private key never leaves the secure element
A certificate suits a primary credential when the private key is generated or written in protected storage on the device, and neither the application nor a debug interface can export it. Only the public key and the certificate request leave the device. A low-cost device that cannot do this may still use a certificate, but it should be treated as easier to copy. It needs a shorter validity and stricter revocation. It cannot share the same "trust for a long time" policy as a device with a secure element.
The platform should keep the issuance record: which certificate was issued to which device, when it expires, and which operation issued it. If the certificate exists only on the device and the platform has no index, the objects due for rotation cannot be found before they expire. When an intermediate certificate on the trust chain is rotated, a device that has pinned only the old intermediate will refuse the connection after the platform changes its server certificate. Agree whether the device trusts the root or pins the end-entity certificate, and check a sample of devices before the change. A device with the wrong time misjudges a certificate that is not yet valid or already expired. Time sync is a precondition for enabling certificate authentication, not an option.
Checking only the validity period and not revocation
The validity period says only that the certificate is still inside the calendar range agreed at issuance. When a device is lost, scrapped on the line, or the private key may have leaked, revocation marks a certificate that has not yet expired as untrusted. If the platform checks only the date and the signature, and does not query a revocation list or an online status, a device reported lost keeps connecting until it expires naturally. The policy when a revocation check fails also has to be set in advance: refuse the connection, or, when the check service is unavailable, allow it against a short-lived cache. If that is unstated, a blip in the check service rejects every device at once, or, the other way, a failed check is treated as a pass.
Another mistake is a self-signed certificate whose private key is shared by every device, with the matching public key configured as a trust anchor. Read the private key out of any one device and every device's identity can be forged. Revoking a single unit means nothing. Each device's key pair must be separate. A debug certificate must not enter the production trust list. A certificate used by line fixtures should be limited in product range and validity, and revoked when it leaves the line. If the identity after a successful handshake does not match the device name the message claims for itself, refuse the session. Do not trust the self-reported name in order to stay compatible with old firmware. Compatibility should be done by the identity written at issuance, not by skipping a check that failed.
Issuance and revocation should be authorized separately. If the same person can both issue and delete the issuance ledger with no record, the audit cannot prove that a given certificate ever existed. Keep the ledger at least until the certificate has expired and past the period needed for an investigation. When the certificate serial number reported by the device does not match the ledger, refuse the session and list the difference. Do not automatically trust a new certificate the device brings. Automatic trust lets a replacement certificate pass straight through after a private key has leaked.