Hi,
This is Luca from DAC.
Our system currently communicates with Cumulocity using a Java Agent. We would like to replace the Agent with Thin Edge. Would it be possible to do so without losing any data?
Our idea is to configure Thin Edge to send data to the existing device instance on Cumulocity. Is this feasible?
Best
Luca
Hi Luca,
yes, that will work. All you need to make sure is that thin-edge is using your existing c8y_Serial identity as device.id. This device.id is derived from the CN-field in your certificate.
Practically that means, if you’re having a device with c8y_Serial “AB63-7621-1062” on Cumulocity, you can do:
$ sudo tedge config set c8y.url your-tenant.eu-latest.cumulocity.com
$ sudo tedge cert create --device-id AB63-7621-1062
$ sudo tedge cert upload c8y
$ sudo tedge connect c8y
…and thin-edge connects towards your existing device instead of creating a new one.
In addition to Korbinians response:
You also have to check that the owner of the existing device is either using an existing device-user and same serial as before or needs to be changed to match the pattern Korbinian mentioned.
Otherwise thin-edge might not have access to that device.
So you might need to change the owner to device_<serial> as well if the owner is different to that before.
Hi guys,
I cannot make it work. let me share the steps i followed.
This is the existing device
This is the cert I created using:
tedge cert create --device-id "atc-poc-remoteConnection-102"
Device certificate: /etc/tedge/device-certs/tedge-certificate.pem
Subject: CN=atc-poc-remoteConnection-102, O=Thin Edge, OU=Test Device
Issuer: CN=atc-poc-remoteConnection-102, O=Thin Edge, OU=Test Device
Valid from: Tue, 11 Mar 2025 12:30:29 +0000
Valid up to: Wed, 11 Mar 2026 12:30:29 +0000
Thumbprint: A18EE0CB383C1663B1CFC75B3F179B52C91F1BE4
Uploaded on Cumulocity:
But when I hit
sudo tedge connect --debug c8y
I get:
2025-03-12T12:37:16.89129502Z DEBUG tedge_config::tedge_config_cli::tedge_config_location: Loading configuration from "/etc/tedge/tedge.toml"
Connecting to Cumulocity with config:
device id: atc-poc-remoteConnection-102
cloud profile: <none>
cloud host: t1523338844.cumulocity.com:8883
certificate file: /etc/tedge/device-certs/tedge-certificate.pem
bridge: mosquitto
service manager: systemd
mosquitto version: 2.0.11
2025-03-12T12:37:17.103450393Z DEBUG rustls::client::hs: No cached session for DnsName("t1523338844.cumulocity.com")
2025-03-12T12:37:17.103758111Z DEBUG rustls::client::hs: Not resuming any session
2025-03-12T12:37:17.153300029Z DEBUG rustls::client::hs: Using ciphersuite TLS13_AES_256_GCM_SHA384
2025-03-12T12:37:17.153493702Z DEBUG rustls::client::tls13: Not resuming
2025-03-12T12:37:17.154174766Z DEBUG rustls::client::tls13: TLS1.3 encrypted extensions: [Unknown(UnknownExtension { typ: EllipticCurves, payload: 0014001d001700180019001e01000101010201030104 })]
2025-03-12T12:37:17.154228434Z DEBUG rustls::client::hs: ALPN protocol is None
2025-03-12T12:37:17.154264894Z DEBUG rustls::client::tls13: Got CertificateRequest CertificateRequestPayloadTLS13 { context: , extensions: [SignatureAlgorithms([ECDSA_NISTP256_SHA256, ECDSA_NISTP384_SHA384, ECDSA_NISTP521_SHA512, ED25519, ED448, RSA_PSS_SHA256, RSA_PSS_SHA384, RSA_PSS_SHA512, Unknown(2057), Unknown(2058), Unknown(2059), RSA_PKCS1_SHA256, RSA_PKCS1_SHA384, RSA_PKCS1_SHA512]), Unknown(UnknownExtension { typ: SignatureAlgorithmsCert, payload: 001c040305030603080708080804080508060809080a080b040105010601 })] }
2025-03-12T12:37:17.15432177Z DEBUG rustls::client::common: Attempting client auth
Creating device in Cumulocity cloud... âś—
error: Connection error while creating device in Cumulocity: Connection refused, return code: `NotAuthorized`
What am i missing?
Edit:
Note that the used to send data to the existing device using an authentication based on username-password not on cert like im trying to do with thin edge
Hi Luca,
I was able to reproduce your problem. Now I see the point is how to change the authentication method from Basic to Certificate.
Can you check “Device Management” > “Management” > “Device credentials” if your device user exists there? If yes, delete the user and try sudo tedge connect c8y again. It should fix the error.
However, you might get such an error in sudo tedge connect c8y. (actually I got)
Verifying device is connected to cloud... âś—
error: Failed to verify device is connected to Cumulocity: Local MQTT publish has timed out
warning: Bridge has been configured, but Cumulocity connection check failed.
In that case, try the connection check again. If it passes, there is no issue.
sudo tedge connect c8y --test
If it still doesn’t work, you can try another way to authenticate thin-edge.io with basic auth. This is documented here. SmartREST 1.0 and basic auth | Thin-edge
Hope it will help you.
Rina
Hi @Rina_Fujino
unfortunately I had to backup to your last option i.e. switch to basic auth. Using this authentication I can send data to the existing device.
At the moment we are using smartest 2.0, could this be a problem? we are not forced to use smartrest 1.0 right?
Then, Im having authentication issues using remote connection via ssh. Could this be caused by the basic auth authentication of Thin edge?
Luca
I’ve noticed that there are a few problems with the latest thin-edge.io main branch release (e.g. the long version numbers like Update 2025-03-17: c8y-remote-access-plugin works again on the main branch1.4.3~266+gf4ee98b), however if you use 1.4.2 then everything should work (though you won’t be able to use the tedge config set device.id in version 1.4.2 so you will have to create a dummy certificate with the correct device id for now until we fix the problem on the main branch)
I’d still recommend sticking with certificates instead of using basic auth, and the key to making it work is just to delete the existing user before you register the certificate (I’ve tested going from cert => basic auth => cert where I deleted the device user after before switching each method).
But if you still insist on using a basic auth user (as maybe your existing agent is using it and you need a clean upgrade path), then all the SmartREST 2.0 operations will stick work fine (in basic auth mode we just subscribe to some additional topics, but there is nothing that will negatively affect the functionality).
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
I finally migrated from the agent to Thin edge mantaining certificate based authentication. The key to the solution as suggested from @Reuben_Miller2 and @Rina_Fujino was to delete the existing device-user. Then the command sudo tedge connect c8y creates a new device user which must match the one that was previously deleted, as suggested by @Stefan_Witschel and @Korbinian_Butz1.