Root CA certificates on devices

Overview

Cloud of Things offers several ways to connect devices to the platform, e.g. using the machine-to-machine (M2M) protocol MQTT (Message Queuing Telemetry Transport) or using REST (Representational State Transfer) APIs via HTTPS. To protect sensitive customer data in communication between devices and the platform, connections are secured at transport layer using the Transport Layer Security (TLS) protocol.

We use TLS every day and almost everywhere in the Internet, but in relation to IoT devices, there are some not negligible challenges when using TLS:

TLS produces communication overhead and increases power consumption.

This section shows the best practice for handling the required (root) certificates on IoT devices.

Transport Layer Security (TLS) Protocol

The Transport Layer Security protocol provides communications security over the Internet. A TLS connection ensures that the data exchanged between IoT devices and the platform is secured over an untrusted medium. The TLS protocol is specified in RFC 5246 (see https://tools.ietf.org/html/rfc5246).

To authenticate communication partners, the TLS layer uses X.509 certificates. After a client starts to establish a TLS ses- sion, the server responds a certificate (and optional additional intermediate certificates) to the client. This certificate con- tains server’s domain name, the validity period of the certificate and the public key of the server.

Certificates and certificate chains

Certificate Authorities (CAs) like https://www.digicert.com issue special X.509 certificates called root certificates which are at the center of the trust model that undergirds Public Key Infrastructure (PKI). Root certificates are absolutely trustworthy and trusted by every internet browser. To protect their root certificates, CAs don’t issue server certificates directly signed by a root certificate. They issue so called intermediate certificates (signed by root certificates) with a shorter validity period which are easier to replace. This intermediate certificates are used to sign server certificates (or other intermediate certificates).

This creates a chain of trust, a so called certificate chain:

Cloud of Things platform validation

When an IoT device opens a TLS session to the Cloud of Things platform, the platform responds with a server certificate (and an intermediate certificate). To verify the validity of the Cloud of Things server certificate, the device must hold the root CA certificate that signed the intermediate certificate which has been used to sign the server certificate.

Important: An IoT device should never trust an intermediate certificate or a server certificate directly, only root CA certificates are trustworthy. So it is always necessary to verify the complete certificate chain.

Root certificates on the device

To establish a secure connection to the Cloud of Things platform it is necessary to check the certificate chain completely. It is absolutely negligent to accept a server certificate without verification or to verify only the server certificate or the intermediate certif- icate(s). To be able to verify the entire certificate chain, an IoT device must store at least the necessary root certificate(s).

A simple method is to store only the required root certificate(s) on the device without the possibility to update them, e.g. as part of the firmware or hardcoded in the software. Although this would be sufficient for the moment it is absolutely not recommended to do so. Even if root certificates have a long validity period, there are several reasons a root certificate may be exchanged in the future:

If the root certificates are not updated in the event of a (root) certificate change, a connection to the Cloud of Things platform is no longer possible. Depending on how the certificates are stored on the device, an update must be performed manually or, for example, the firmware must be updated. So the recommended solution is to implement an updatable certificate trust store as described in chapter 3.

Cloud of Things root certificates

The Cloud of Things platform uses currently three root certificates. The currently used certificate is always on the first place in the list. The Baltimore CyberTrust Root as root of the current server certificate, will be exchanged with the T-TeleSec GlobalRoot Class 2 root certificate in Q1 2022. The rest are backup root certificates which might be used in the future. Please note that the certificate exchange only affects devices that transmit data to the Cloud of Things via REST or MQTT. Please check to what extent your devices are affected by this and update the certificates used if necessary. Instructions for changing certificates on PSsystec devices can be found on the manufacturer’s pages at: PSsystec certificate documentation

Baltimore CyberTrust Root (currently used until Q1 2022, will be removed from this list after exchange)

Thumbprint (SHA-1): d4 de 20 d0 5e 66 fc 53 fe 1a 50 88 2c 78 db 28 52 ca e4 74

Download: https://dl.cacerts.digicert.com/BaltimoreCyberTrustRoot.crt

See also https://www.digicert.com/digicert-root-certificates.htm or https://crt.sh/?id=76

T-TeleSec GlobalRoot Class 2 (next certificate used from Q1 2022, will move to the top of this list)

Thumbprint (SHA-1): 59 0d 2d 7d 88 4f 40 2e 61 7e a5 62 32 17 65 cf 17 d8 94 e9

Download: https://www.telesec.de/assets/downloads/PKI-Repository/T-TeleSec_GlobalRoot_Class_2.cer

See also (https://www.telesec.de/de/root-programm/informationen-zu-ca-zertifikaten/root-zertifikate/ or https://crt.sh/?id=8733622

DigiCert Global Root CA (currently not used, backup 1)

Thumbprint (SHA-1): A8 98 5D 3A 65 E5 E5 C4 B2 D7 D6 6D 40 C6 DD 2F B1 9C 54 36

Download: https://cacerts.digicert.com/DigiCertGlobalRootCA.crt

See also https://www.digicert.com/digicert-root-certificates.htm or https://crt.sh/?id=4385364571

VeriSign Universal Root Certification Authority (currently not used, backup 2)

Thumbprint (SHA-1): 36 79 ca 35 66 87 72 30 4d 30 a5 fb 87 3b 0f a7 7b b7 0d 54

Download: https://www.websecurity.symantec.com/content/dam/websitesecurity/digitalassets/desktop/pdfs/roots/VeriSign-Universal-Root-Certification-Authority.pem

See also https://www.websecurity.symantec.com/theme/roots or https://crt.sh/?id=1039083

PEM format

The PEM format (Privacy-Enhanced Mail) is a common format for storing certificates in files, which are Base64 encoded text files. PEM certificates are often used for web servers because they can contain multiple certificates. In addition to the server certificate, they usually also contain the intermediate certificates of the certificate chain. As a consequence, the PEM format can also be used to store several root certificates in one file. The PEM file of the currently used certificate, the next used certificat and a backup certificate are stored on the support tenant and can be found under following Links:

Current setup

Setup after certificate exchange

The Cloud of Things root certificates look like this in PEM format:

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ
RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD
VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoX
DTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9y
ZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVy
VHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKr
mD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjr
IZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeK
mpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSu
XmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZy
dc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/ye
jl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1
BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3
DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT92
9hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3Wgx
jkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0
Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhz
ksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLS
R9I4LtD+gdwyah617jzV/OeBHRnDJELqYzmp
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIDwzCCAqugAwIBAgIBATANBgkqhkiG9w0BAQsFADCBgjELMAkGA1UEBhMCREUx
KzApBgNVBAoMIlQtU3lzdGVtcyBFbnRlcnByaXNlIFNlcnZpY2VzIEdtYkgxHzAd
BgNVBAsMFlQtU3lzdGVtcyBUcnVzdCBDZW50ZXIxJTAjBgNVBAMMHFQtVGVsZVNl
YyBHbG9iYWxSb290IENsYXNzIDIwHhcNMDgxMDAxMTA0MDE0WhcNMzMxMDAxMjM1
OTU5WjCBgjELMAkGA1UEBhMCREUxKzApBgNVBAoMIlQtU3lzdGVtcyBFbnRlcnBy
aXNlIFNlcnZpY2VzIEdtYkgxHzAdBgNVBAsMFlQtU3lzdGVtcyBUcnVzdCBDZW50
ZXIxJTAjBgNVBAMMHFQtVGVsZVNlYyBHbG9iYWxSb290IENsYXNzIDIwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCqX9obX+hzkeXaXPSi5kfl82hVYAUd
AqSzm1nzHoqvNK38DcLZSBnuaY/JIPwhqgcZ7bBcrGXHX+0CfHt8LRvWurmAwhiC
FoT6ZrAIxlQjgeTNuUk/9k9uN0goOA/FvudocP05l03Sx5iRUKrERLMjfTlH6VJi
1hKTXrcxlkIF+3anHqP1wvzpesVsqXFP6st4vGCvx9702cu+fjOlbpSD8DT6Iavq
jnKgP6TeMFvvhk1qlVtDRKgQFRzlAVfFmPHmBiiRqiDFt1MmUUOyCxGVWOHAD3bZ
wI18gfNycJ5v/hqO2V81xrJvNHy+SE/iWjnX2J14np+GPgNeGYtEotXHAgMBAAGj
QjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBS/
WSA2AHmgoCJrjNXyYdK4LMuCSjANBgkqhkiG9w0BAQsFAAOCAQEAMQOiYQsfdOhy
NsZt+U2e+iKo4YFWz827n+qrkRk4r6p8FU3ztqONpfSO9kSpp+ghla0+AGIWiPAC
uvxhI+YzmzB6azZie60EI4RYZeLbK4rnJVM3YlNfvNoBYimipidx5joifsFvHZVw
IEoHNN/q/xWA5brXethbdXwFeilHfkCoMRN3zUA7tFFHei4R40cR3p1m0IvVVGb6
g1XqfMIpiRvpb7PO4gWEyS8+eIVibslfwXhjdFjASBgMmTnrpMwatXlajRWc2BQN
9noHV8cigwUtPJslJj0Ys6lDfMjIq2SPDqO/nBudMNva0Bkuqjzx+zOAduTNrRlP
BSeOE6Fuwg==
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9w0BAQUFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGExCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IENBMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1eqUKKPC3eQyaKl7hLOllsB
CSDMAZOnTjC3U/dDxGkAV53ijSLdhwZAAIEJzs4bg7/fzTtxRuLWZscFs3YnFo97
nh6Vfe63SKMI2tavegw5BmV/Sl0fvBf4q77uKNd0f3p4mVmFaG5cIzJLv07A6Fpt
43C/dxC//AH2hdmoRBBYMql1GNXRor5H4idq9Joz+EkIYIvUX7Q6hL+hqkpMfT7P
T19sdl6gSzeRntwi5m3OFBqOasv+zbMUZBfHWymeMr/y7vrTC0LUq7dBMtoM1O/4
gdW7jVg/tRvoSSiicNoxBN33shbyTApOB6jtSj1etX+jkMOvJwIDAQABo2MwYTAO
BgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUA95QNVbR
TLtm8KPiGxvDl7I90VUwHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUw
DQYJKoZIhvcNAQEFBQADggEBAMucN6pIExIK+t1EnE9SsPTfrgT1eXkIoyQY/Esr
hMAtudXH/vTBH1jLuG2cenTnmCmrEbXjcKChzUyImZOMkXDiqw8cvpOp/2PV5Adg
06O/nVsJ8dWO41P0jmP6P6fbtGbfYmbW0W5BjfIttep3Sp+dWOIrWcBAI+0tKIJF
PnlUkiaY4IBIqDfv8NZ5YBberOgOzW6sRBc4L0na4UU+Krk2U886UAb3LujEV0ls
YSEY1QSteDwsOoBrp+uvFRTp2InBuThs4pFsiv9kuXclVzDAGySj4dzp30d8tbQk
CAUw7C29C79Fv1C5qfPrmAESrciIxpg0X40KPMbp1ZWVbd4=
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIEuTCCA6GgAwIBAgIQQBrEZCGzEyEDDrvkEhrFHTANBgkqhkiG9w0BAQsFADCB
vTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwOCBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MTgwNgYDVQQDEy9W
ZXJpU2lnbiBVbml2ZXJzYWwgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0wODA0MDIwMDAwMDBaFw0zNzEyMDEyMzU5NTlaMIG9MQswCQYDVQQGEwJVUzEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAyMDA4IFZlcmlTaWduLCBJbmMuIC0gRm9y
IGF1dGhvcml6ZWQgdXNlIG9ubHkxODA2BgNVBAMTL1ZlcmlTaWduIFVuaXZlcnNh
bCBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAx2E3XrEBNNti1xWb/1hajCMj1mCOkdeQmIN65lgZOIzF
9uVkhbSicfvtvbnazU0AtMgtc6XHaXGVHzk8skQHnOgO+k1KxCHfKWGPMiJhgsWH
H26MfF8WIFFE0XBPV+rjHOPMee5Y2A7Cs0WTwCznmhcrewA3ekEzeOEz4vMQGn+H
LL729fdC4uW/h2KJXwBL38Xd5HVEMkE6HnFuacsLdUYI0crSK5XQz/u5QGtkjFdN
/BMReYTtXlT2NJ8IAfMQJQYXStrxHXpma5hgZqTZ79IugvHw7wnqRMkVauIDbjPT
rJ9VAMf2CGqUuV/c4DPxhGD5WycRtPwW8rtWaoAljQIDAQABo4GyMIGvMA8GA1Ud
EwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMG0GCCsGAQUFBwEMBGEwX6FdoFsw
WTBXMFUWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFI/l0xqGrI2Oa8PPgGrUSBgs
exkuMCUWI2h0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28uZ2lmMB0GA1Ud
DgQWBBS2d/ppSEefUxLVwuoHMnYH0ZcHGTANBgkqhkiG9w0BAQsFAAOCAQEASvj4
sAPmLGd75JR3Y8xuTPl9Dg3cyLk1uXBPY/ok+myDjEedO2Pzmvl2MpWRsXe8rJq+
seQxIcaBlVZaDrHC1LGmWazxY8u4TB1ZkErvkBYoH1quEPuBUDgMbMzxPcP1Y+Oz
4yHJJDnp/RVmRvQbEdBNc6N9Rvk97ahfYtTxP/jgdFcrGJ2BtMQo2pSXpXDrrB2+
BxHw1dvd5Yzw1TKwg+ZX4o+/vqGqvz0dtdQ46tewXDpPaj+PwGZsY6rp2aQW9IHR
lRQOfc2VNNnSj3BzgXucfr2YYdhFh5iQxeuGMMY1v/D/w1WIg0vvBZIGcfK4mJO3
7M2CYfE45k+XmCpajQ==
-----END CERTIFICATE-----

Certificate trust store

A certificate store is used to manage and securely store digital certificates on a computer system. A special kind of certifi- cate store is the certificate trust store, where only the public part of public key certificates is stored. A certificate trust store is also used to manage certificate revocation lists (CRLs) which describe invalid or untrustworthy certificates. Certificate trust stores are typically part of the operating system (Microsoft Windows, macOS, iOS, Android,…) and contain a collection of root certificates which are used by internet browsers to verify server certificates.

It is strongly recommended to implement a certificate trust store on IoT devices to manage and store the root certificates needed to verify Cloud of Things server certificates. Intermediate certificates are provided by the Cloud of Things servers and should never be stored in the certificate trust store on the device.

Initialization and update

The required root certificates must be initially available on the device to verify the validity of the Cloud of Things server certificate when establishing a secure connection to the Cloud of Things platform. Root certificates can be downloaded separately from the issuing certification authority (CA), e.g., at https://www.digicert.com/digicert-root-certificates.htm to download root certificates issued by DigiCert (see also download links in section Cloud of Things root certificates.

As a result of root certificates can change, it is strongly recommended to store several root certificates on the device in a certificate trust store. As mentioned before, certificate trust stores are usually part of the operating system, but IoT devices normally don’t run a full operating system. It is also not recommended to integrate the root certificate(s) or a certificate trust store into device firmware, because each update concerning the certificate chain means that a new firmware version has to be rolled out.

Our recommendation is to setup a certificate trust store that can be updated independent from device firmware updates and implement an update process that periodically verifies the locally stored root certificates (validity period, trustworthiness), removes invalid or untrusty ones and get newly issued root certificates.

To initially fill and update the certificate trust store with root certificates we recommend to use external sources as described in the following section.

Root Certificate Store / Mozilla Network Security Services

Certificate trust stores are usually part of the operating system and manufacturers like Microsoft, Apple or Google provide update mechanisms (e.g. operating system patches) or offer a possibility to download a set of root certificates, e.g.:

Another easy to use source for root certificate collections is Mozilla’s Network Security Services (NSS), a set of libraries designed to support cross-platform development of security-enabled applications. Mozilla products (like the Firefox browser) and many other internet applications (e.g. Google Chrome for Linux) use the NSS framework. Further information about NSS can be found at https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS.

There is also a root store included in NSS that contains all root certificates Mozilla products (like Firefox Browser) trust. It can be found at https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt. It is regularly updated and as of 13.08.2019 it contained 154 trusted root certificates. A list of all included root certificates can be found at https://wiki.mozilla.org/CA/Included_Certificates.

The certdata.txt file contains some information about the level of trust in each root but not all restrictions recommended by Mozilla on the roots are encoded in this file. Some are implemented in NSS, so we recommend to use always the latest NSS library collection instead of the certdata.txt file standalone. In addition, it offers the advantage that implementations are independent from future changes like a new URL for certdata.txt.

Restrictions that are not included in certdata.txt file are documented at https://wiki.mozilla.org/CA/Additional_Trust_Changes.

Further information about the Network Security Services libraries can be found at https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/An_overview_of_NSS_Internals.

https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F gives some notes how to use Mozilla’s set of root certificates.