This article explains how clients and products establish a trusted SSL connection to the DPS backend (including the built-in connectors) and how to keep the CA certificates up to date throughout the life of your products.
Certificate download URLs
Devices with limited hardware resources for storing and managing certificates can download the CA certificate directly from one of the URLs below.
AWS
Environment Type | Region | Certificate URL |
|---|---|---|
Sandbox | Europe (Ireland) | |
Production | Europe (Ireland) | |
Production | Asia/Pacific (Hong Kong) |
AZURE
Environment Type | Region | Certificate URL |
|---|---|---|
Develop | Europe (Frankfurt) | |
Staging | Europe (Frankfurt) | |
Production | Europe (Frankfurt) |
For more details on the types of environments, see Environment Types and Limits article.
Note that these endpoints are served over plain HTTP by design.
CA certificates are public information, and a device whose trust store is out of date would not be able to complete an HTTPS handshake.
How the certificate chain works
The SSL connection to Servitly is based on a chain of three levels:
Level | Provided by | Typical validity |
|---|---|---|
Root CA certificate | Generally embedded in the device operating system | Up to 15 years |
Intermediate CA certificate | Sent by the server during the handshake | Long-lived (years) |
End-entity certificate | Sent by the server during the handshake | Renewed periodically (90 days) |
The Servitly end-entity certificate has a short validity and is renewed every 90 days (it will be 60 days), which is a routine and transparent operation for the device.
CA certificates last much longer, but they are not immutable: a certificate authority may change its root chain with short notice, or Servitly may switch to a different CA altogether. In both cases, the certificates are renewed.
Do not hard-code CA certificates in your devices
CA certificates must not be stored within the device without a way to update them remotely.
Consider the scenario where the CA certificate is hard-coded in the devices you sell. As soon as that certificate changes, the connection to Servitly (MQTT, API, or any other supported protocol) is no longer possible, and the device requires a firmware update to keep working.
If the device relies on the Servitly built-in firmware update feature, that path is unavailable too: firmware updates are based on IoT Connector messages exchanged between the backend and the client, and the IoT Connector connection is exactly what the outdated certificate breaks. Recovery then requires an alternative channel, such as USB, Wi-Fi, or Bluetooth.
A preventive remote update is not a reliable safeguard either, since part of your fleet may be turned off at the time of the certificate change.
Recommended approach
Download the CA certificate from the URL matching your environment and store it in a location the firmware can overwrite at runtime.
Trigger the download:
at device power-up;
when a connection error occurs;
periodically, independently of errors.
If you are planning to use a custom domain in the future, your firmware should also be able to handle the domain change, so that it keeps validating the hostname the device is connecting to.