beA-Anbindung gestört 6

Dieser Eintrag wurde veröffentlicht unter Uncategorized am von

24.03. 13:17 Uhr: beA-Support bestätigt Änderungen im Betrieb des beA

Der beA-Support teilt zu meiner Frage, warum nicht mehr wie bisher beide (Test- und produktive) Zertifikate im Zertifikatespeicher vorgehalten werden können, folgendes mit:

„Es gab in den letzten Monaten einige Anpassungen an der Load-Balancer/Firewall Infrastruktur, möglicherweise hat dies dazu geführt dass ein ‚Durchprobieren‘ nicht mehr möglich ist. Vielen Dank für den Hinweis!“

23.03. 20:11 Uhr: Installer verfügbar

Es stehen jetzt für alle Plattformen neue Client-Installer bereit. Wer bereits Version 2.3 installiert hat, muss lediglich den Client-Installer erneut ausführen, der Server bleibt unverändert. Neben der beA-Änderung sind folgende zusätzliche Änderungen enthalten:

  • Etikettenselektion / Darstellung angepasst: inaktive Etiketten haben ebenfalls ein Icon, um ein „Springen“ bei Selektion / Deselektion zu vermeiden.
  • Kalenderblatt: ganztägige Termine, Probleme mit Selektion / Mausklick-Koordinaten
  • Etiketten an Adresse nun auf erstem Tab
  • Layout-Korrekturen Adresse
  • Gegenstandswert / Schadennummer auf anderen Tab verschoben
  • Darstellungsproblem Aktensuche (Farben) korrigiert
  • Anpassung für IONOS-Mailkonten

Sollte nach Installation beim Start ein Fehler erscheinen, sollte der Client einmal deinstalliert und dann erneut installiert werden. Dabei bzgl. LibreOffice die Option „vorhandene Installation nutzen“ wählen.

Das Zertifikateproblem ist technisch noch nicht vollständig geklärt – ich arbeite weiter mit dem beA-Support der BRAK, um die Ursache genau zu verstehen. Mit dem heutigen j-lawyer.org-Release wurde ein Zertifikat für die „Testumgebung“ entfernt – jedoch sollten zusätzliche Zertifikate im Zertifikatespeicher niemals zu einem solchen Fehler führen. Seit der ersten beA-Anbindung liefert j-lawyer.org den Client immer mit beiden Zertifikaten aus.

23.03. 17:52 Uhr: Installer in Arbeit

Die Tests für Windows- und Mac-Arbeitsplätze verliefen soweit erfolgreich, für Linux noch nicht.

23.03. 12:30 Uhr: Anpassungen im Test

Neue Client-Installer wurden über Mailingliste den Testanwenderinnen / Testanwendern zur Verfügung gestellt.

23.03. 11:45 Uhr: technische Hintergrundinformationen

Aktuell wird die Zertifikatseinbindung erneut geprüft. Grundsätzlich ist für einen Zugang zur beA-Schnittstelle ein Zertifikat notwendig, und es gibt separate Zertifikate für bspw. die sogenannte Schulungs-/Partner-/Testumgebung und das produktive beA. Seit Existenz der beA-Anbindung in j-lawyer.org wird die Anwendung mit beiden Zertifikaten ausgeliefert, sodass zwischen beiden Umgebungen gewechselt werden kann. Unsererseits wird nun geprüft, ob evtl. das „falsche“ Zertifikat verwendet und das alternative gar nicht mehr genutzt wird.

23.03. 10:30 Uhr: Zertifikatsproblem

beA-Support bestätigt den Verdacht eines Zertifikateproblems: „Von gestern auf heute wurde die Zertifikatsprüfung auf der Prod-Umgebung wieder aktiviert.“

Anmerkung: weder gab es eine Kommunikation, dass die Zertifikatsprüfung deaktiviert war, noch dass sie gestern / heute wieder reaktiviert wird.

23.03. 8:47 Uhr: anscheinend kein reines j-lawyer.org – Problem

Zwei weitere Kanzleisoftware-Hersteller melden das gleiche Fehlerbild.

23.03. 8:00 Uhr: beA-Support kontaktiert

Seit letzter Nacht funktioniert die beA-Integration von j-lawyer.org nicht mehr.

Nach derzeitigem Kenntnisstand (nur unsererseits, nicht durch die BRAK verifiziert) handelt es sich um ein Zertifikatsproblem – der beA-Server liefert HTTP 503.

Nur: mit dem letzten Update wurde von uns bereits ein neues Zertifikat ausgeliefert, es ist bis Oktober 2029 gültig, und hat seit dem Update auch funktioniert.

Der BRAK-Support ist kontaktiert, und wir informieren an dieser Stelle fortlaufend.

Schreibe einen Kommentar

6 Gedanken zu “beA-Anbindung gestört”

  • N. Peter

    Habe den Client-Installer neu heruntergeladen und ausgeführt. Beim Start von J-Lawyer kommt jetzt folgende Meldung:
    java.lang.NoSuchMethodError: ‚java.lang.ClassLoader org.apache.logging.log4j.util.StackLocatorUtil.getCallerClassLoader(int)‘
    at org.apache.log4j.Logger.getLogger(Logger.java:40)
    at com.jdimension.jlawyer.client.settings.ClientSettings.(ClientSettings.java:793)
    at com.jdimension.jlawyer.client.Main.main(Main.java:785)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:84)
    at com.exe4j.runtime.WinLauncher.main(WinLauncher.java:94)
    at com.install4j.runtime.launcher.WinLauncher.main(WinLauncher.java:25)

      • N. Peter

        Das stimmt, Sorry, aber so findet vielleicht jemand schneller die Lösung, falls er oder sie das gleiche Problem aufgrund der beA-Störung hat 😉
        Deinstallation und erneute Installation hat funktioniert, jetzt geht die beA-Integration wieder. Danke für die schnelle Reaktion!

        LG

  • fragend

    beA-Login fehlgeschlagen: null
    Habe den Client-Installer neu heruntergeladen und ausgeführt – nichts geholfen. Client-Installer deinstalliert und erneut installiert – nichts gebracht. Nutzer hat alle Rechte, Zertifikat ist korrekt, Passwort auch, Häkchen bei „automatisch mit Zertifikat anmelden“ gesetzt – was könnte man noch tun? Danke.