Skip to content

Overview of Certificate Management in the Industrial Edge Ecosystem

Certificates are essential for securing communication and establishing trust between various components in the Industrial Edge ecosystem. The management of these certificates varies slightly across different offerings within Industrial Edge Management (IEM).

The Role of IEM in Secure Communication

IEM provides an HTTPS endpoint for device and user communication (via browser). To establish secure communication, a chain of trust must be configured. This involves updating the client's certificate store (whether on a PC, browser, or device) with the root certificate employed by the IEM.

certificate flow

Chain of Trust Explained

A chain of trust is a security model that verifies the authenticity and integrity of a certificate. It begins with a trusted root certificate issued by a Certificate Authority (CA) and often includes an intermediate certificate, which links the root certificate to the end-user certificate. Each certificate in the chain validates the next one, ensuring that the connection remains secure.

When a device or browser establishes a connection, it checks the entire chain—root, intermediate, and end-user certificates—confirming that each certificate is valid and ultimately trusted by the root CA.

Certificate Lifecycle Management

Certificates follow a defined lifecycle that includes issuance, usage, expiration, and renewal/revocation. Key aspects of this lifecycle include:

  • Expiration Time: Regular certificates (e.g., server or device certificates) usually have shorter expiration times of one to two years to ensure outdated or potentially compromised certificates are frequently renewed. In contrast, root certificates have longer expiration times of 10 to 25 years to maintain stability in the chain of trust, as they serve as the foundation for many devices and systems globally.

Understanding Public Trust Stores and Private Root Certificates in IEDs

Industrial Edge Devices (IEDs) utilize a public trust store to verify certificate authenticity during HTTPS communications. This store is a collection of trusted root and intermediate certificates from recognized Certificate Authorities (CAs), pre-installed on most devices and browsers. Public root certificates allow IEDs to securely connect to external services without additional configuration.

Moreover, IEDs support the integration of private root certificates, enabling customers to utilize their corporate Public Key Infrastructure (PKI). This feature facilitates secure internal communication within private networks, allowing devices and services to authenticate using the customer’s certificate authority for enhanced security and flexibility.

Managing Certificate Stores on IEDs

Effective management of the certificate store on IEDs is critical for secure communication. This process varies based on whether the device uses the public trust store or a private root certificate chain:

  • Public Trusted Certificates: The public trust store is automatically managed via firmware updates, ensuring the latest trusted root and intermediate certificates are maintained without manual intervention.

  • Private Root Certificates: Customers using a private root CA provide the certificate chain via an onboarding file during IED setup. This chain is added to the internal trust store, allowing validation of IEM certificates against the private root chain during communication.

Certificate Import Guidelines

When importing certificates, the following guidelines should be adhered to:

  1. Full Chain: Include the full chain of trust—server certificate, intermediate certificates, and root certificate (if using a private root CA)—to ensure the certificate is verifiable by clients without fetching intermediates separately.

  2. Common Name (CN): Should represent the primary domain of the web server (e.g., CN = ). For wildcard certificates, include the wildcard character (e.g., CN = *.example.com).

  3. Subject Alternative Name (SAN): Must list all domain names the certificate should secure (e.g., DNS: example.com, DNS: ). SAN is mandatory for modern browsers.

Certificate Key and Algorithm Requirements

  • Key Length: For RSA, use a minimum of 2048-bit key length; for ECC, use curves like P-256 or P-384.
  • Algorithm: Use secure hashing algorithms such as SHA-256 or higher; signing algorithms should be SHA-256 with either RSA or ECDSA.

Certificate Validity and Renewal

  • Validity Period: Certificates should have a maximum validity of 1 year (398 days). Shorter validity periods are recommended for enhanced security.
  • Renewal: Implement automated certificate renewal processes to avoid service disruptions. Test the renewal process to ensure minimal impact on the web service.

NOTICE

If a private root certificate is used and the root certificate is changed after the onboarding of the Industrial Edge Devices (IED), ensure that the new root certificate is imported to the IED to maintain trust and secure communications.

Further Guides

Summary of Certificate Types

Public Trust Store

  • Contains certificates from publicly recognized CAs.
  • Pre-installed on most devices, browsers, and operating systems.

Private Root Certificate Chain

  • Used within closed, private environments such as IEM.
  • Issued by an organization's private CA, requiring manual addition to devices' trust stores.
  • Ensures secure communication in controlled environments, not trusted by default on external devices.