Elli Wallbox eebus not detected

[vheat]

Today (2022-05-31) Elli distributed a new firmware of Elli Wallbox (ID.charger and other Volkwagen models). This offers eebus interaction. However evcc-io/eebus does neither recognize the mDNS coming from the wallbox nor the wallbox lists the EVCC for a HEMS. Looks like the mDNS is also not recognized correctly by the box.

If needed I can provide a wireshark trace for the mDNS (both sources).

There are notices around that SMA can deal with the Elli for EEbus control, also the SMA looks to have some issues showing the Elli, but this is just early information.

I'm trying to get the EEbus SHIP specifcation to verify the mDNS records.

In EVCC log level trace there is not any indication of an mDNS entry being received (in [eebus] and other records)

[ginsolvibile]

Same here. evcc 0.94 and Elli Wallbox updated to the latest firmware.

I can confirm receiving mDNS / SHIP announcements from the wallbox, with tcpdump I see SRV records with apparently valid A and AAAA fields.

The "evcc charger" returns nothing, and from the wallbox web UI I see no available "energy managers".

@vheat the SHIP specs are publicly available, let me know if you did not find them.

My wallbox config block in evcc.yaml is

- type: template
  template: eebus 
  ski: ABxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3A
  enforcePVLimits: true  
  name: wallbox3

I have some experience with Go and had a quick look at the SHIP and SPINE specifications, if there's anything I can do to help in debugging this issue I will be glad to.

[andig]

@ginsolvibile SHIP only happens after the discovery. Without any logging I'm still unsure what exactly fails during discovery.

@DerAndereAndi mentioned mDNS but I'm not sure what goes wrong.

It would probably help to have the Go mDNS listener to add some logging.

[DerAndereAndi]

I am on it with some success and some problems. Not done yet. The current implementation is not compatible, you need to wait.

[ginsolvibile]

@ginsolvibile SHIP only happens after the discovery. Without any logging I'm still unsure what exactly fails during discovery.

What I can see via wireshark is that the wallbox sends 3 mDNS queries (AAAA, A and SRV) and then immediately answers itself. The SRV query is:

Elli-Wallbox-1234xxxxxx._ship._tcp.local: type SRV, class IN, "QM" question
    Name: Elli-Wallbox-1234xxxxxx._ship._tcp.local
    [Name Length: 40]
    [Label Count: 4]
    Type: SRV (Server Selection) (33)

and the corresponding answer is

Elli-Wallbox-1234xxxxxx._ship._tcp.local: type SRV, class IN, cache flush, priority 0, weight 0, port 4712, target wallbox-1234xxxxxx.local
    Service: Elli-Wallbox-1234xxxxxx
    Protocol: _ship
    Name: _tcp.local
    Type: SRV (Server Selection) (33)
    .000 0000 0000 0001 = Class: IN (0x0001)
    1... .... .... .... = Cache flush: True
    Time to live: 120 (2 minutes)
    Data length: 27
    Priority: 0
    Weight: 0
    Port: 4712
    Target: wallbox-1234xxxxxx.local

@DerAndereAndi mentioned mDNS but I'm not sure what goes wrong.

It would probably help to have the Go mDNS listener to add some logging.

Let me know if you want me to do some tests on my network.

[ginsolvibile]

I am on it with some success and some problems. Not done yet. The current implementation is not compatible, you need to wait.

Thank you @DerAndereAndi and @andig for all the work you've done, implementing eebus from scratch must have been a challenging task. After 2 years waiting for Elli to deliver the protocol they promised :) I can certainly wait all the time you need.

I'm available for further testing, if you need.

[DerAndereAndi]

The problem with mDNS here is the zeroconf library. Elli can not see the mDNS entry from this library and the library only sometimes sees entries from the Elli wallbox. When it does see the Elli wallbox, there are always some mandatory items missing, either the network record or the TXT record.

I implemented a workaround to use the native avahi linux system when available. That way discovery works flawlessly. My desire to make zerconf work here is very very low.

For ship to work I already have some fixes, they were minor. The bigger task is SPINE, as they use EEBUS very differently compared to Porsche/Audi and also very buggy (e.g. don't providing lots of mandatory data). I got the communication running, but the box still shows with its LED that the HEMS is not active and charging is fixed to 6A per current. All changes are accepted in EEBUS but ignored. I am trying to somehow get hold on someone at Elli.

The other remaining issue is the certificate Elli or better EVBox uses (they are the 3rd party building the wallbox and developing the software). The certificate is not conforming to the DER standard and marking the isCA flag with 0x1 for true instead of 0xFF and go crypto checks for 0xFF and rejects the certificate otherwise. More info here: https://forum.golangbridge.org/t/x509-certificate-parse-error-with-iot-device/27622/2

[andig]

Ich hab mal bei GE angefragt ob jemand von VW mit liest.

[andig]

@ginsolvibile

What I can see via wireshark is that the wallbox sends 3 mDNS queries

You could try the _ship._tcp queries in Go and check why Go doesn't decode the responses (if you can see them on tcpdump).

[vheat]

For more discussions see https://github.com/evcc-io/evcc/discussions/1217#discussioncomment-2866752

[StefanSchoof]

I am not an asn.1 expert, but if I read https://docs.microsoft.com/en-us/windows/win32/seccertenroll/about-boolean correct the bool is a valid true.

[DerAndereAndi]

Here the expertise from an SSL expert (not me):

..., im Debugger sieht man dass im Zertifikat von der Elli eine 0x01 kommt, cryptobyte/asn1.go erwartet aber 0xFF.

In der zugehörigen Spec zu ASN.1 https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.690-202102-I!!PDF-E&type=items Chapter 8.2 steht aber, dass alles außer 0x00 dann TRUE ergeben soll. Insofern ist go cryptobyte/asn1.go falsch.

Dann, der commit 06a226f https://cs.opensource.google/go/x/crypto/+/793ad666bf5ec61392092b27061be9618e4e219b:cryptobyte/asn1_test.go;bpv=1;bpt=0;drc=06a226fb4e3765ef3f48aa2852b401bc7b98e981;dlc=18b771bd64f19baf6611ce73e30afe2e1a50082c führt den Test ein und verweist hier auf DER in Chapter 11.1 und da steht dann tatsächlich, dass alle Bits 1 sein sollen.

...

... sage ich mal, BER oder DER beschreiben die „encoding rules“, also wie sollte es eingepackt werden. Cryptobyte macht das Decoding und da könnte man das m.E. etwas relaxter handeln. Frage für mich wäre, ob beim Cert irgendwas steht, das es DER encrypted ist, also der Decoder auch DER machen soll. Dann wäre das Problem bei Elli. Evtl kann man ja auch beim TLS einstellen, wie das Cert decodiert werden soll, ob DER oder BER. Da ich in Cryptobyte aber keine Möglichkeit sehe, zwischen BER und DER zu unterscheiden, ist das müßig zu diskutieren.

Ich denke, Cryptobyte sollte die Condition beim Decodieren relaxen. Beim Encodieren machen sie immer 0 oder FF. Sie scheinen den Anspruch zu haben einen ASN1 DER En-/Decoder zu haben.

...

Elli könnte man auch ansprechen, die X.509 Spec https://datatracker.ietf.org/doc/html/rfc5280#section-4.1 sagt, das ein V3 Cert nach DER encodiert sein soll. Hier ist Elli definitiv falsch.

Ich hab im Moment nur den RFC, die ISO wird dem aber vermutlich nicht widersprechen ISO/IEC 9594-8:2020 https://www.iso.org/standard/80325.html

[vheat]

Das Cert der Elli bekommt man mit openssl s_client -connect 192.168.1.180:4712 -showcerts Bitte IP und Port entsprechend dem mDNS Eintrag für SHIP der Elli setzen. Für HTTPS/Port 443 ist das Cert korrekt (FF)

Aus dem Ergebnis das Cert ausschneiden (von BEGIN bis END CERTIFICATE und z.B. in wallbox.crt kopieren) Das Cert der Elli kann dann man auseinander nehmen mit :~/wallbox$ openssl asn1parse -in wallbox.crt .... 275:d=4 hl=2 l= 12 cons: SEQUENCE
277:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 282:d=5 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:3003010101 289:d=4 hl=2 l= 29 cons: SEQUENCE
... Da sieht man sehr schön die fehlerhafte 01

Der freie OSS Nokalva ASN1 Decoder
https://asn1.io/PKI-inspector/default.aspx? (bitte X.509 auswählen) markiert die BasicConstraints der Elli auch rot als Fehler, decodiert aber dennoch nach TRUE. Ein FF würde ohne Fehler angezeigt.

Da scheint die Elli intern die Certs für https und SHIP unterschiedlich zu erzeugen.

[andig]

Bzgl. SSL: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/ schreibt:

ASN.1’s main serialization format is “Distinguished Encoding Rules” (DER). They are a variant of “Basic Encoding Rules” (BER) with canonicalization added. For instance, if a type includes a SET OF, the members must be sorted for DER serialization.

Ich würde das Go issue aufmachen, weiß aber nicht wie ich mit

Frage für mich wäre, ob beim Cert irgendwas steht, das es DER encrypted ist, also der Decoder auch DER machen soll.

umgehen soll. Kann der Experte vllt nochmal sagen, ob/wie man ihm das ansieht? Hilfreich wäre auch ein Callstack von der Stelle wo das Bool Decoding aussteigt- dann wüsste man wenigstens was Go da in den höheren Levels gerade versucht.

[andig]

Allerdings sieht das schlecht aus: https://github.com/golang/go/issues/48210#issuecomment-913506442

It looks like there's no plan to add BER support

[andig]

Aber vielleicht hilft das ja: https://github.com/go-asn1-ber/asn1-ber

[vheat]

Hallo, ich bedanke mich für die Blumen :-) Also die ASN1 Spec findet man hier https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.690-202102-I!!PDF-E&type=items

Direkt die Introduction in dieser Spec sagt, Seite v

This Recommendation | International Standard defines encoding rules that may be applied to values of types defined using
the ASN.1 notation. Application of these encoding rules produces a transfer syntax for such values. It is implicit in the
specification of these encoding rules that they are also to be used for decoding.

Damit ist Decoding wie Encoding und die Position von cryptobyte ist akzeptabel. Elli ist damit definitiv falsch. Schaut man sich die Decodierung z.B. mit dem freien OSS Nokalva https://asn1.io/PKI-inspector/ an, meldet der zwar keinen harten Fehler, markiert die BasicConstraints aber rot, um das Problem anzuzeigen.

Persönlich fände ich auch gut, die Varianz im TLS Cert möglichst gering zu halten, insofern hat die TLS/X.509 Spec auch DER gewählt. Es stört uns nur im Moment... Aber ich denke kurz-/mittelfristig muss Elli hier nachbessern, Ich halte ein falsch encodiertes TLS Cert schon für problematisch.

[vheat]

Der asn1-ber vergleicht für BOOLEAN True mit be.go line 365

        case TagBoolean:
            val, _ := ParseInt64(content)

            p.Value = val != 0

Ebenso beim Encoding Line 526, da wird einfach der Wert != 0 genommen.

func NewBoolean(classType Class, tagType Type, tag Tag, value bool, description string) *Packet {
    intValue := int64(0)

    if value {
        intValue = 1
    }
    p := Encode(classType, tagType, tag, nil, description)
    p.Value = value
    p.Data.Write(encodeInteger(intValue))

Sollten wir den BER Code allgemein verwenden, könnten wir an anderer Stelle in Problem laufen, sollte die Elli intern dann doch DER machen.

Nur als Randbemerkung, das Cert, dass die Elli für https / lokales Config Interface verwendet, ist korrekt mit 0xFF kodiert.

[andig]

Bleibt die Frage wie wir die Library überhaupt nutzen könnten:

    // VerifyPeerCertificate, if not nil, is called after normal
    // certificate verification by either a TLS client or server. It
    // receives the raw ASN.1 certificates provided by the peer and also
    // any verified chains that normal processing found. If it returns a
    // non-nil error, the handshake is aborted and that error results.
    //
    // If normal verification fails then the handshake will abort before
    // considering this callback. If normal verification is disabled by
    // setting InsecureSkipVerify, or (for a server) when ClientAuth is
    // RequestClientCert or RequireAnyClientCert, then this callback will
    // be considered but the verifiedChains argument will always be nil.

Der zweite Absatz dürfte der spannende sein. Jetzt müsste man mal testen, ob sich die Verifikation damit umgehen lässt. Ich fürchte aber auch das würde das Problem nicht lösen, da uns das Zertifikat denn nicht zum Verschlüsseln zur Verfügung stünde?

[DerAndereAndi]

Nein, die Methode kann man nicht verwenden, er steigt vorher aus.

In https://github.com/golang/go/blob/master/src/crypto/tls/handshake_client.go#L856 geht er aus verifyServerCertificate raus. In der gleichen Methode in https://github.com/golang/go/blob/master/src/crypto/tls/handshake_client.go#L892 würde VerifyPeerCertificate aufgerufen.

Hilft also leider nicht. Es scheint es gibt hier nur 2 Lösungen:

• Go erlaubt den invaliden Wert 1
• Elli erstellt auf den Geräten ein neues Zertifikat, was auch zur Konsequenz hätte dass alle bisher gekoppelten HEMS Systeme neu gekoppelt werden müssten

Übersehe ich eine Lösungsvariante?

[vheat]

Ich seh eigentlich nur die zweite Lösung, Elli benutzt hier ein formal inkorrektes Zertifikat (soll DER sein). Lösung 1 wäre für mich ein Workaround bis dahin. Gibt es bei Go eine Möglichkeit, privat einen Patch auf ein vorhandenes Paket zu setzen?

[StefanSchoof]

Ein anderer (aber auch kein schöne) Möglichkeit wäre das über einen Proxy, der das Zert akzeptiert und ein eignes Präsentiert laufen zu lassen.

[DerAndereAndi]

Ich hatte versucht das in ein eigenes gepatchtes Crypto Paket zu forken, aber die internen Abhängigkeiten sind recht groß, so dass ich davon abgelassen habe. Einen anderen Weg das "schön" zu patchen, ist mir nicht bekannt. Vielleicht hat da aber @andig eine Idee, er hat da viel mehr Erfahrung.

Ob und bis Elli das korrigiert, wird kein kurzfristiger Prozess sein, sondern eher Monate dauernd (nach meiner Erfahrung).

Ein Proxy zu nutzen ist nicht trivial möglich. Es muss zwischen den Geräten eine stehende TLS WebSocket Verbindung geben und Informationen aus dem Zertifikat in ein Proxy Zertifikat müssten transparent übersetzt werden, da diese Zertifikatsinfos auch in der weiteren Kommunikation relevant sind. Nach meiner Einschätzung wäre das extrem viel Arbeit und zu wissen ob das auch funktionieren könnte. Den Aufwand imho nicht Wert.

[andig]

Ich seh eigentlich nur die zweite Lösung, Elli benutzt hier ein formal inkorrektes Zertifikat (soll DER sein). Lösung 1 wäre für mich ein Workaround bis dahin. Gibt es bei Go eine Möglichkeit, privat einen Patch auf ein vorhandenes Paket zu setzen?

Ja, go mod replace. Das wäre auch die Lösung um die zeroconf ohne Codeänderungen auszutauschen. Ich weiss allerdings nicht, ob das auch mit internen Modulen funktioniert- wäre aber einen Versuch wert (kann ich auch testen).

Ein anderer (aber auch kein schöne) Möglichkeit wäre das über einen Proxy, der das Zert akzeptiert und ein eignes Präsentiert laufen zu lassen.

Coole Idee. Gibts da was?

[DerAndereAndi]

Ja, go mod replace. Das wäre auch die Lösung um die zeroconf ohne Codeänderungen auszutauschen. Ich weiss allerdings nicht, ob das auch mit internen Modulen funktioniert- wäre aber einen Versuch wert (kann ich auch testen).

Kann man damit auch einzelne Files ersetzen? Das Modul zu extrahieren um es zu patchen hatte ich versucht aber die internen Querverbindungen (Referenzen auf /internal im Root) waren mit dann zu viel.

Ich versuche das mal fix nur mit Cryptobyte

Update: bekomme es nicht hin.

[DerAndereAndi]

libp2p/zeroconf hat das Interface ganz leicht geändert. Man kann nun einige Zeilen Init Code (den Resolver) rauslassen. D.h. ich würde da schon wechseln und dann evtl. mit replace auf nen Fork gehen. Da das momentan noch nicht viel bringt, würde ich erst mal warten ob die das mergen bzw. wie lange das dort dauert.

[andig]

Ich versuche das mal fix nur mit Cryptobyte Update: bekomme es nicht hin.

Ich denke das geht nur auf ganze Module und nicht einzelne Packages :( Und dann hängst Du wieder an den internal Dependencies. Geht wohl nicht :(

[andig]

https://groups.google.com/g/golang-nuts/c/-wJDIS2DZEI/m/JCVtzkpNAwAJ

[andig]

libp2p/zeroconf hat das Interface ganz leicht geändert.

@DerAndereAndi könntest Du den PR auch gegen die originale zeroconf auf machen? Der Fork ist nicht "offiziell" und es wäre zumindest schön auch Upstream die Möglichkeit zu geben, damit zu arbeiten und noch ist das Repo deutlich populärer. https://github.com/grandcat/zeroconf/issues/27#issuecomment-1148576616 scheint mir im Fork ebenfalls nicht gelöst zu sein. Ich kanns sonst auch gerne rüber schieben...

[StefanSchoof]

Ein anderer (aber auch kein schöne) Möglichkeit wäre das über einen Proxy, der das Zert akzeptiert und ein eignes Präsentiert laufen zu lassen.

Coole Idee. Gibts da was?

Ich habe noch nichts benutzt. Per Google habe ich welche gefunden. "Leider" viele in go geschrieben, so dass sie nicht wahrscheinlich helfen können (https://github.com/suyashkumar/ssl-proxy, https://github.com/ghostunnel/ghostunnel). Gibt auch was in rust https://lib.rs/crates/proxyboi

[DerAndereAndi]

Update: hab es hinbekommen und den Branch einfach von nem älteren Commit gemacht: https://github.com/grandcat/zeroconf/pull/108

[andig]

@DerAndereAndi willst Du einen PR hier mit replace directive auf Deinen Commit machen? Sonst mache ich das. Anders gefragt: willst Du die Fehler überhaupt noch hier fixen oder direkt auf Deine EEbus Implementierung umsteigen?

[DerAndereAndi]

Meine neue EEBUS Implementierung ist noch nicht so weit dass sie hier genutzt werden könnte.

Habe hier commits für einen PR vorbereitet, inkl. mDNS. Wobei ich hier aber auch auf den zeroconf fork schon gegangen bin. Es wird ein draft sein, weil die Elli trotz erfolgreicher Kommunikation das HEMS noch nicht akzeptiert und daher keine Steuerung möglich ist.

[andig]

@vheat willst Du bei go-nuts antworten? Macht keinen Sinn wenn ich versuche zu übersetzen?

[vheat]

In go-nuts wurde nach einer zu-Fuß-Anfrage via openssl gefragt, das Ergebnis erschreckt. Zeigt aber das cryptobyte und TLS definitiv richtig liegen, sich zu sträuben. Es gibt einen Handshake Failure, fragt sich, wie Elli das getestet haben kann.

We receive an alert 40 (Handshake failure ) when using openssl. So the cert is definitively faulty in some way. But this applies only for the websocket port 4712. Applying same command for port 443 (local config interface) does not return any error the handshake passes.

:~/wallbox/hack$ openssl s_client  -connect 192.168.1.180:4712 
CONNECTED(00000005)
depth=0 CN = EEBUS, O = EVBox Intelligence, C = NL
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = EEBUS, O = EVBox Intelligence, C = NL
verify return:1
140477570593216:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1528:SSL alert number 40
---
Certificate chain
0 s:CN = EEBUS, O = EVBox Intelligence, C = NL
   i:CN = EEBUS, O = EVBox Intelligence, C = NL
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIBszCCAVmgAwIBAgIBATAKBggqhkjOPQQDAjA6MQ4wDAYDVQQDDAVFRUJVUzEb
...

[StefanSchoof]

Ich habe mir noch mal die dates des Zertifikates angeschaut:

cat wall.crt | openssl x509 -noout -dates
notBefore=Jan 22 17:13:21 2022 GMT
notAfter=Jan 17 17:13:21 2042 GMT

Wenn es am notBefore Zeitpunkt erstellt wurde, das ist ungefähr als die Firmware v3.7.12 veröffentlicht wurde.

Gibt es eine Möglichkeit, dass wir die Box mit der aktuellen Firmware zum Erzeugen eines neuen Zertifikates bewegen. Vielleicht ist das ja schon in der Erzeugung der aktuellen Firmware gefixt.

[vheat]

Hallo @StefanSchoof, in der Box habe ich keine Möglichkeit gesehen, eigene Certs einzubringen, es gibt wohl nur die, die die Box mitbringt. Macht zum Teil auch Sinn, da das andere Interface, also via Internet zum Backend in OCPP2.x, sich mit einem Rechner vermutlich bei VW verbindet und auch nur dahin verbinden soll. Die Apps am Handy greifen auf dieses Backend zu, um ihre Infos abzuholen. Insofern erwarte ich, dass die Box bei den Certs fix ist, 2042 dürfen wir sie vermutlich alle wegwerfen :-) ... k.A. - oder es gibt doch eine Möglichkeit zum Zertifikatsupdate, auch wenn mich das notBefore daran zweifeln lässt... zu lang zurück für ein kontinuierliches Cert-handling.

... Sri, hab falsch gelesen, das Cert startet 2022 insofern gibts eine Cert-Updatemöglkichkeit, also warten auf Update.

[DerAndereAndi]

Das Cert wurde auf dem Gerät erzeugt. Es gibt aber keine Möglichkeit für uns das von aussen irgendwie zu triggern. Außerdem würde das Cert dann weiterhin mit dem Fehler erzeugt werden. Das kann man nur durch ein Firmware Update korrigieren.

[andig]

Zeigt aber das cryptobyte und TLS definitiv richtig liegen, sich zu sträuben. Es gibt einen Handshake Failure, fragt sich, wie Elli das getestet haben kann.

...und dennoch bekommen wir mit gepatchtem Go eine Verbindung? Man muss es wohl so sehen: das Zertifikat ist nach Goldstandard openssl fehlerhaft- in dem Fall erübrigt sich dann auch die Diskussion über ASN.1/Cryptotype.

[StefanSchoof]

Das Cert wurde auf dem Gerät erzeugt. Es gibt aber keine Möglichkeit für uns das von aussen irgendwie zu triggern. Außerdem würde das Cert dann weiterhin mit dem Fehler erzeugt werden. Das kann man nur durch ein Firmware Update korrigieren.

Aber das Cert wurde ja mit einer alten Firmware (v3.7.12) erzeugt und wir können doch nicht ausschliesen, dass die Firmware v3.8.12 das richtig macht. (Ich weiß das ist ein Long Shot...)

Sollte ein Factory Reset ein neues Cert erzeugen?

[DerAndereAndi]

Da wir nicht wissen wie die Logik intern ist: Keine Ahnung. Vielleicht. Vielleicht auch nicht.

[vheat]

Die Chance für ein neues Cert ist groß, ob das richtig ist allerdings fraglich. Die 3.7.12 wurde am 17.1. veröffentlicht, damit ist das Cert vom 22.1. danach entstanden. https://www.elli.eco/en/changelog/wallbox Laut Copyright sind mit 3.8.12 die EVbox Componenten alle in einer neuen Version reingekommen. Das Problem ist eigentlich zu offensichtlich, um nicht aufgefallen zu sein. Ob dann allerdings der EEbus besser läuft ... ist ebenfalls fraglich. Mal sehen wer sich als erster vor die Box setzt :-)

[DerAndereAndi]

So, ich hab mir den Spaß gerade gegönnt. All Zertifikate wurden neu erzeugt, Fehler bleibt bestehen.

Ansonsten fällt der Fehler nicht auf, wenn die genutzten HEMS Testgeräte das Zertifikat entweder nicht so genau prüfen oder trotzdem akzeptieren. Und mir scheint das tun alle.

[vheat]

Da wir an dem Thema dran sind und Elli ja hoffentlich mitliest :-) , in der Diskussion bei https://groups.google.com/g/golang-nuts/c/-wJDIS2DZEI/m/fjdMSru0AwAJ wird erwähnt, dass das Cert auch einen Subject Alternative Name enthalten soll (künftige golang Versionen). Das https Cert hat den Subject Alternative Name, siehe unten, beim EEbus Cert fehlt das auch.

Vielleicht wäre es seitens Elli auch eine Option, beide Certs durch den Anwender updatebar zu machen (Hochladen im Config Interface). Bei OCPP2.x ist das vermutlich keine Option, da das Backend ja nur mit bekannten Boxen(=bekanntes Cert) sprechen möchte.

prompt> openssl x509 -in elli_https.crt -text
...
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:TRUE
            X509v3 Subject Alternative Name: 
                IP Address:192.168.123.4
...

[DerAndereAndi]

Spätestens damit haben wir dann ein Problem. Ich habe hier Geräte von 3 verschiedenen Herstellern, keiner davon hat das!

Porsche/Audi:

        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Subject Key Identifier:
                2F:A1:D6:C6:6E:52:89:C3:D7:81:17:78:92:0C:29:CA:C2:F0:42:D1
            X509v3 Authority Key Identifier:
                keyid:2F:A1:D6:C6:6E:52:89:C3:D7:81:17:78:92:0C:29:CA:C2:F0:42:D1
                DirName:/C=DE/O=Bebro/OU=ULK High GEN 1/CN=ICCPD_EEB_ULKH_BBF-00203.08.2000033238
                serial:01

SMA:

        X509v3 extensions:
            X509v3 Subject Key Identifier:
                50:1D:74:01:3E:68:EA:20:38:61:35:12:D3:29:63:B4:E9:F5:A8:36
            X509v3 Authority Key Identifier:
                50:1D:74:01:3E:68:EA:20:38:61:35:12:D3:29:63:B4:E9:F5:A8:36
            X509v3 Basic Constraints:
                CA:TRUE

Und Elli:

        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Subject Key Identifier:
                46:B9:64:2E:68:4F:C5:27:41:87:48:7A:AD:35:A0:50:8E:32:DE:3E
            X509v3 Authority Key Identifier:
                46:B9:64:2E:68:4F:C5:27:41:87:48:7A:AD:35:A0:50:8E:32:DE:3E

Ich kann dort gerne Antworten und auch die Certs zur Verfügung stellen.

[andig]

Mal langsam :)

Recent versions of Go won't verify the certificate unless it contains a subjectAltName; matching against only the CN is no longer supported. So if you do get your vendor to re-issue the cert, make sure it also includes a DNS SAN, if it doesn't already. It doesn't matter if it's just a string like "EEBUS"; you can specify the ServerName at connection time.

Ich glaube das ist erstmal kein Problem da wir das Zertifikat per se ja gar nicht verifizieren wollen. Das zu tun wäre Bonus.

However if openssl s_client does talk to it, then you have another workaround: you could exec.Cmd an instance of openssl s_client, and pipe data to and from it.

Die Idee ist doch als Workaround for time being ganz lustig- zumindest solange man kein Windows verwendet?

Ansonsten fällt der Fehler nicht auf, wenn die genutzten HEMS Testgeräte das Zertifikat entweder nicht so genau prüfen oder trotzdem akzeptieren. Und mir scheint das tun alle.

Ich hab mich gefragt mit welchen anderen HEMS man das überhaupt gerade testen könnte- was hast Du da im Einsatz das EEBus spricht?

[DerAndereAndi]

Die Idee ist doch als Workaround for time being ganz lustig- zumindest solange man kein Windows verwendet?

Lustig vielleicht von technischer Seite, aber persönlich finde ich das uninteressant und befürchte das ist nicht so trivial wie es vielleicht klingen mag. Vergiss nicht dass der SKI (sha1.sum vom privaten key) für die Verbindung übereinstimmen muss. Ist jetzt nichts womit ich mich persönlich beschäftigen möchte.

Ich hab mich gefragt mit welchen anderen HEMS man das überhaupt gerade testen könnte- was hast Du da im Einsatz das EEBus spricht?

Ich habe hier einen SMA Home Manager 2.0. Was willst du da genau testen?

[DerAndereAndi]

Aber ja du hast natürlich Recht: Verification haben wir eh ausgeschaltet. Von daher ist das kein Problem.

[DerAndereAndi]

Man könnte auch versuchen beim Build immer einen patch auf die entsprechende asn1.go Datei auf die lokale go Kopie durchzuführen, bis Elli das gefixt hat. Ein Workaround, auch nicht schön, aber wohl weniger aufwändig.

Aber egal wie, die richtige Lösung ist, dass das Zertifikat von Elli korrekt erstellt wird.

[andig]

Ich habe hier einen SMA Home Manager 2.0. Was willst du da genau testen?

Ich wollte nur verstehen, was schon geht. Kann der SHM tatsächlich über EEBus steuern? Auch mit der Elli???

[DerAndereAndi]

Nein, der SMA Home Manager 2.0 kann mit keinem EVSE über EEBUS reden. (Sonst wäre ich wohl nie auf die Idee gekommen an dem EEBUS Stack zu arbeiten, danke SMA 😁 )

Mein Code kann mit der Elli reden, ich habe ein ausführliches langes kommentiertes Log File hier. Nur akzeptiert die Elli keine LoadLimit Änderungen. Hatte ich im anderen Thread auch schon erwähnt: https://github.com/evcc-io/evcc/discussions/1217#discussioncomment-2903632 Warum das so ist, weiss ich nicht. D.h. selbst wenn wir jetzt das Zertifikatsproblem gelöst bekommen, brauche ich dafür auch noch Input von Elli. Auch das ist aber bereits eingetütet. Können bei beidem momentan nur warten.

Potentielle HEMS Systeme die funktionieren könnten sind:

• Hager (kenne niemanden)
• Porsche HEMS (kenne niemanden der den und den Elli Charger hat)
• SMA Data Manager M lite mit Charge S Software Upgrade (warte auf Feedback von jemandem der beides hat)