search

thin-edge / thin-edge.io_examples

Apache License 2.0
6 stars 18 forks source link

ThinEdge can't connect to tenant #31

Closed smeus closed 2 years ago

smeus commented 2 years ago

We are using the example from https://github.com/thin-edge/thin-edge.io_examples/tree/main/opcua-solution.

grafik

Two weeks before we could connect via ThinEdge to our tenant. At the moment it is not possible.

Thanks in advance for your support.

PradeepKiruvale commented 2 years ago

Could you please share which version thin-edge you are using.

smeus commented 2 years ago

The version of the thin-edge is 0.6.1

mbay-ODW commented 2 years ago

I just double checked with the same version on adamos.com and adamos-dev.com with no issues. I have the feeling that there is something within the network not properly configured in terms of DNS. Can you describe your setup a bit more and provide the Dockerfile etc?

smeus commented 2 years ago

We modified the dockerfile to transfer the certificate, the key and the baseUrl via the .env file. Then via a shell script the certificate and key are copied in the respective folder. The script launches tedge disconnect c8y to disconnect any possible bridges to the c8y cloud, set the baseUrl via tedge config set c8y.url ${baseUrl} and finally connects to the cloud via tedge connect c8y. Everything else is the same except some additions to make running the shell script work via openRC in the dockerfile.

albinsuresh commented 2 years ago

Could you do an nslookup ${baseUrl} from inside that container to rule out any networking misconfiguration?

mbay-ODW commented 2 years ago

Did you rebuild the docker container after the 21st of May? I just saw that there was a jump in the base image version from 3.15 -> 3.16 about 10 days ago. The Dockerfile uses :latest tag.

smeus commented 2 years ago

@albinsuresh: the nslookup was ok. The IP was the same I got over a Windows ping. @mbay-ODW: Yes, I already rolled the alpine version back because it was causing the /sbin/init Entrypoint to fail

I did some research myself and apparently we had a certificate problem, which caused this kind of behaviour. After generating new certificates the error message is gone.

albinsuresh commented 2 years ago

@smeus A corrupt certificate "appearing" as DNS lookup error is confusing and we'd like to improve that error reporting from thin-edge if possible. So, could you please share some details of that certificate issue?

smeus commented 2 years ago

@albinsuresh: At first we tried to get the connection working via our own certificate and private key file. This would lead to a not authorized error message. The key file was an encrypted private key, but the header and footer stated just -----BEGIN PRIVATE KEY----- and -----END PRIVATE KEY-----. That was probably the issue. To check if the connection was working normally, we removed the certificate inside the container via tedge cert remove and then generated ( tedge cert create ) a new one. When trying to upload the new test certificate the above mentioned error message was displayed.

mbay-ODW commented 2 years ago

@albinsuresh Customer found out that this was based on the fact that he encrypted the certificates via -sha256. I guess this should be considered somewhere in the documentation that the certificate should not be encrypted. And of course some log message that indicates that something is wrong with the certificate.