search

enbility / eebus-go

EEBUS protocol implementation in go
https://enbility.net
MIT License
52 stars 14 forks source link

External TLSConfig #63

Closed elgohr closed 1 year ago

elgohr commented 1 year ago

Some devices, like the Elli Wallbox, come with a certificate that was signed by some random companies CA. These CAs don't need to be generally trusted. In this way it would be great to externalize the TLSConfig of the server and client, so that people can handle these connections.

elgohr commented 1 year ago

Talking about https://github.com/enbility/eebus-go/blob/dev/service/hub.go#L251 and https://github.com/enbility/eebus-go/blob/dev/service/hub.go#L363

DerAndereAndi commented 1 year ago

Hi,

the TLS config needs to be this way, as it is defined by the SHIP specification chapter 9. Any EEBUS certificate is locally signed. The Elli certificate is invalid as it does not follow the TLS specification and for it to be accepted, either Elli needs to fix this (they know it) or go needs to be patched as done in the evcc project: https://github.com/evcc-io/evcc/blob/master/Makefile#L134-L144

Is the reason for the rejection of the Elli certificate without patching go the reason for your request?

elgohr commented 1 year ago

Correct, I don't want to tinker within go for making this work.

DerAndereAndi commented 1 year ago

There sadly is no other way. I debugged this intensively and it came down to this. Either Elli fixes this in a software update, or you need to patch go. :(

elgohr commented 1 year ago

As said, if tls.Config would be part of the service.Configuration, people can decide on their own, whether to strictly follow the specs or support a device that doesn't.

Removing ClientAuth: tls.RequireAnyClientCert solves the connection issue.

DerAndereAndi commented 1 year ago

There was a long discussion on this issue here: https://github.com/evcc-io/eebus/issues/1

Interesting, I need to check this. As far as I remember it did not work last year when I tried to find a solution.

people can decide on their own, whether to strictly follow the specs or support a device that doesn't.

In general: the proper way in any case is for Elli to fix this and they are aware of it since 1 year. If someone wants to implement a energy manager with this library, it would mean to always ignore the certificate for any device (unless they make their configuration process more complex). OpenSSL also shows the cert error, but ignores it. Go is more strict in this scenario.

elgohr commented 1 year ago

Interesting, I need to check this.

Tested on go version go1.20.3 darwin/arm64

Totally agree that Elli should fix this - I was just looking for something faster :-)

DerAndereAndi commented 1 year ago

There is a Slack channel, if you are interested :) See https://enbility.net/contact/

Did you check if this works for initiating the connection also? Right now I am thinking of: if this works for both cases, handle this inside eebus-go instead of having the user handle this explicitly. Normally the developer using eebus-go doesn't know about all the cases that could happen in the wild. Would be great to discuss this in Slack :)

DerAndereAndi commented 1 year ago

As a heads up, I tried removing TLSClient and also using ClientAuth: tls.NoClientCert,, but when initiating a connection it always fails with:

2023-06-07 13:24:08 DEBUG connection to 55e7a4fc41cb7460a211cd9adec4f662557b179b failed: tls: failed to parse certificate from server: x509: invalid basic constraints b

Pairing the device from the Elli web interface works and it says pairing is complete, but it never actually initiates a working communication by itself.