• Bewerte uns auf OMR Reviews: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

Gelöst [Gelöst] Neues Zertifikat wird bei Verwendung der edi@energy-Richtlinie abgelehnt

GeHe

Member
Registriert
20 April 2023
Beiträge
14
Reaktionspunkte
5
Moin,
ein Marktpartner (50Hertz) hat ein neues Zertifikat übermittelt. Nun ist gestern die erste damit verschlüsselte Nachricht empfangen worden, diese wird von NSP abgewiesen mit "Die Signatur-Parameter der Nachricht und des Zertifikats sind nicht kompatibel (RFC 4056, Abschnitt 3)"
Wenn ich altes und neues Zertifikat vergleiche ist (neben dem anderen Aussteller) der einzige Unterschied der Schlüsseltyp (alt RSA 2048, neu RSA 4096).
Wir benutzen NSP 4.0.5.39 und haben die edi@energy-Richtlinie aktiviert.

Gibt es dazu bekannte Probleme?

Danke und Gruß
Georg
 
kleines Update:

so war es auch, denn sie haben es korrigiert und nun kommen die edi Mails auch wieder auch durch, weil nun die Signatur der BDEW Richtlinie entspricht

1707813995516.png
 
Hallo Sören,
ja, sie haben es geändert, weil dies der schnellste Weg war. Allerdings interpretieren Sie den Abschnitt
"5.3 Algorithmen und Schlüssellängen
für S/MIMEEs sind folgende Algorithmen und Schlüssel mit den genannten Schlüssellängen zu verwenden:
Einstellungen in der Software:
Signatur:
  • Hashfunktion (Hash algorithm): SHA-256 oder SHA-512 (gemäß IETF RFC 5754).
  • Signaturverfahren (Signature algorithm): RSASSA-PSS (gemäß IETF RFC 4056)."
so, dass die Wahlfreiheit bei der Hashfunktion unabhängig von der bei der Signatur verwendeten Funktion besteht. Bislang seien wir auch der einzige Marktpartner, der das bemängelt habe.
Ich habe eine entsprechende Frage im BDEW-Forum gestellt, die ich hier verlinke, sobald sie beantwortet wurde. Falls der BDEW der Interpretation des Marktpartners folgt wäre eine Anpassung im NSP notwendig, ich erwarte dies aber nicht.
 
Allerdings interpretieren
da gibt es nichts zu interpretieren, sie müssen sich an die RFC für RSASSA-PSS halten und da steht ganz klar:
1. The hashAlgorithm field in the certificate
subjectPublicKey.algorithm parameters and the signatureAlgorithm
parameters MUST be the same.

Signatur:
  • Hashfunktion (Hash algorithm): SHA-256 oder SHA-512 (gemäß IETF RFC 5754).
  • Signaturverfahren (Signature algorithm): RSASSA-PSS (gemäß IETF RFC 4056)."
Der Teil hier kommt von EDI@ENERGY.... das bedeutet, aber nicht, dass man an der RFC vorbei operieren darf :D

Natürlich dürfen und haben sie die Wahl ob sie eine SHA256 oder SHA512 aufbringen, sie dürfen dabei aber nicht die RFC 4056 brechen. Wenn sie eine SHA512Signatur aufbringen wollen, dann MUSS der Signaturhashalgorithmus des verwendeten Keys ebenfalls SHA512 sein.

ich erwarte dies aber nicht
ich auch nicht, auch das BDEW muss sich an gängige Standards, auf die sie ja selbst auch verweisen, halten

Bislang seien wir auch der einzige Marktpartner, der das bemängelt habe.
Da fehlen mir etwas die Worte, wenn man so anfängt zu argumentieren ;)

Ich danke für deinen Einsatz :) Bin mal gespannt ob irgendeine Meldung aus dem BDEW-Forum dazu kommt.
 
Zuletzt bearbeitet:
Ich habe eine entsprechende Frage im BDEW-Forum gestellt, die ich hier verlinke, sobald sie beantwortet wurde. Falls der BDEW der Interpretation des Marktpartners folgt wäre eine Anpassung im NSP notwendig, ich erwarte dies aber nicht.
Ich wäre Dir sehr dankbar, wenn Du in dem Forum darauf drängst, dass die RFC eingehalten werden muss. Alles andere wäre absolut lächerlich und der Sache in keinster Weise dienlich. Ich verweise gerne noch einmal auf den jüngsten Vorfall, der unter dem Namen "SMTP Smuggling" bekannt wurde. Grund für diesen durchaus gravierenden Vorfall war eine Nichtbeachtung der RFC.
 
Vielen Dank für den Hinweis,
ja, wir haben ebenfalls das Problem gehabt und deswegen auch ein Ticket bei Euch, NSP, erstellt. Das kann demnach geschlossen werden (schreibe ich extra).
Ja, der Zertifikatsaussteller procilon hat beim Signieren der von ihm ausgestellten Zertifikate auf SHA-512 umgestellt. Das habe aber wohl nur wenige von deren Kunden (50hertz.com am 8.2. 11:00) mitbekommen und versenden ihre GPKE-Nachrichten mit dem procilon-als-Aussteller-Zertifikat weiterhin mit SHA-256 gehasht. Dann knallt es entsprechend. Also müssen diese Partner auf diesen hier diskutierten Umstand hingewiesen werden.
 
.... Bislang seien wir auch der einzige Marktpartner, der das bemängelt habe.
Wir hatten das auch bei mehreren (7 oder mehr) Marktpartnern bemängelt, konnten aber nicht die exakte Ursache benennen. Jetzt können wir das so an diese weitergeben - vielen Dank
 
Ich wäre Dir sehr dankbar, wenn Du in dem Forum darauf drängst, dass die RFC eingehalten werden muss. Alles andere wäre absolut lächerlich und der Sache in keinster Weise dienlich. Ich verweise gerne noch einmal auf den jüngsten Vorfall, der unter dem Namen "SMTP Smuggling" bekannt wurde. Grund für diesen durchaus gravierenden Vorfall war eine Nichtbeachtung der RFC.
Da musste ich nicht drängen ;)
 
Danke für den Hinweis @wewert , aber aus meiner Sicht muss das schon die Software-Lösung von alleine machen. Die Lösung muss automatisch den verwendeten Hash im Zertifikat erkennen und dementsprechend auch die richtige Hash-Funktion beim Signieren verwenden. Wie schon gesagt, die RFC ist da mehr als eindeutig. Dass man das manuell umstellen kann, ist kein Feature, sondern ein Bug. </ragemode> ;-)
 
Danke für den Hinweis @wewert , aber aus meiner Sicht muss das schon die Software-Lösung von alleine machen.... die RFC ist da mehr als eindeutig. Dass man das manuell umstellen kann, ist kein Feature, sondern ein Bug. </ragemode> ;-)
Ja, nur das ist deren Software-Lösung; wir können trotzdem nur unsere Kommunikationspartner darauf hinweisen. ;-)
 
Ich habe eine entsprechende Frage im BDEW-Forum gestellt, die ich hier verlinke, sobald sie beantwortet wurde. Falls der BDEW der Interpretation des Marktpartners folgt wäre eine Anpassung im NSP notwendig, ich erwarte dies aber nicht.
Gab es da mal ein Feedback?
 
Hallo alle miteinander,

ich möchte gerne an dieser Stelle etwas Licht und Klarheit in das Thema bringen:
Das BDEW hat die gestellt Frage beantwortet und ist dabei recht "zurückhaltend" geblieben: BDEW Forum

Ich bin der Thematik jedoch auf Grund eines Support Tickets einmal nachgegangen und muss leider mitteilen, dass wir einen Bug im Produkt haben.
Wir arbeiten bereits an einer Korrektur um das Problem schnellstmöglich aus der Welt zu schaffen.

Referenz ID: 41530

Beste Grüße,
Jan
 
Zurück
Oben