Communication ID for devices without namespaces

Typically, device types should always be assigned namespaces. If this is not possible for a device or is not desired, the ID can also be structured as follows:

Option1

The communication ID corresponds to a device property:

Syntax

urn:bosch:dp:id:<device-type-name>.<category-name>.<attribute-name>.<attribute-value>

Example of a device with a unique MAC address under device type 'myDeviceType'

urn:bosch:dp:id:myDeviceType.BLUETOOTH.mac.008041aefd7e

Option2

The communication ID corresponds to a sequential number:

Syntax

urn:bosch:dp:id:<device-type-name>(.<id-type-or-prefix>).<id-value>

Example of a device that can be identified by a sequential number under the device type 'myDeviceType'

urn:bosch:dp:id:myDeviceType.seq.123456 or urn:bosch:dp:id:myDeviceType.123456

Switching communication from basic auth (test mode) to mutual TLS (productive mode)

The recommended method of communication between the device and the Device Portal is Mutual TLS. X.509 certificates are issued for the device with which the device can authenticate itself to the Device Portal.

Since it would be complicated to whitelist each device certificate in the Device Portal, only intermediate certificates are considered for this in the Device Portal.

Therefore, to create a device certificate, you must first create the intermediate certificate:

Generate a X.509 certificate and use .cer , .crt , or .pem as the file extension. The attribute subject CN must be described with a unique value and cannot be empty.

The generated file is the intermediate certificate.
Send the generated intermediate certificate to the Service – Helpdesk.
The Support Team will whitelist the certificate in the Device Portal.
If an Artifact Repository is used, whitelist the intermediate certificate in your Artifact Repository.

The description of the intermediate certificate whitelists can be found in the API documentation of the Artifact Repository.
Generate a new X.509 certificate and use .cer , .crt , or .pem as the file extension. The subject CN must contain the Communication ID as the value.

The generated certificate is the device certificate.
Sign the device certificate with the intermediate certificate using Certificate Signing Request (CSR).
Implement mutual TLS communication for device communication. During connection to the Device Portal, the device receives the Device Portal server certificate and the intermediate certificate with which it was signed. The root certificate used to sign the intermediate certificate should be added to the trusted store of the device.

Now use the URL cert.device.deviceportal.bosch.com to communicate with the Device API.
- Communication between the device and Device Portal on a mutual TLS basis has been implemented.
  If a device certificate has to be blacklisted again later, this is possible via the Helpdesk. If an Artifact Repository is used, a user with the role repository manager must blacklist the device certificate. By blacklisting the device certificate, the Device Portal blocks all further communication with the device..