beA Schlüsselverwaltung unter Debian 9 Teil 2

So langsam werde ich brastig.

Bereits im ersten Teil hatte ich über ein Problem bei der Anwendung der Schlüsselverwaltung des beA berichte, denn dass Passwort lässt sich unter Debian 9 nicht ändern, obwohl das sichere Email-Postfach plattformübergreifend für Windows, Mac und Linux bereitgestellt werden sollte. Eine Supportanfrage wurde zwar umgehend mit dem Angebot einer Fernwartung beantwortet. Darüber hinaus teilte die im Auftrag der Zertifizierungsstelle der Bundesnotarkammer handelnde procilon IT-Solutions GmbH mit, Debian benötige zwingend Oracle JDK einschließlich dessen javaws. Zudem könne der folgende anzupassende Befehl weiterhelfen:

java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -Dprocilon.psf.config=/home/nutzer/.secureframework/SecureFramework/Operations.xml -jar ~/.secureframework/OperationsService-1.2.0-46-jar-with-dependencies.jar

Ich antwortete wie folgt:

Ich habe Oracles Java 8 neben OpenJDK 8 ebenfalls installiert und auf
Standard gesetzt:

sudo update-alternatives --config java

Ausgabe:

[sudo] Passwort für nutzer:
Es gibt 2 Auswahlmöglichkeiten für die Alternative java (welche /usr/bin/java bereitstellen).

Auswahl Pfad Priorität Status
————————————————————
0 /usr/lib/jvm/java-8- oracle/jre/bin/java 1081 automatischer Modus
1 /usr/lib/jvm/java-8- openjdk-amd64/jre/bin/java 1081 manueller Modus
* 2 /usr/lib/jvm/java-8- oracle/jre/bin/java 1081 manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein:

Dann habe ich Ihre Befehle angepasst und ausgeführt. Obwohl die Datei vorhanden ist, erhalte ich beim zweiten Befehl den Hinweis, es existiere weder ein solches Verzeichnis, noch die Datei. Da helfen auch weder sudo noch su.

Den dritten Befehl kennt das System nicht. Hier die  Ausgabe:

~$ java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1
Verwendung: java [-options] class [args…]
           (zur Ausführung einer Klasse)
   oder  java [-options] -jar jarfile [args…]
           (zur Ausführung einer JAR-Datei)
wobei options Folgendes umfasst:
    -d32      Verwendet ein 32-Bit-Datenmodell, sofern verfügbar
    -d64      Verwendet ein 64-Bit-Datenmodell, sofern verfügbar
    -server      zur Auswahl der „server“ VM
                  Die Standard-VM ist server,
                  weil die Ausführung auf einem Server-Class-Rechner erfolgt.

    -cp <Klassensuchpfad von Verzeichnissen und ZIP-/JAR-Dateien>
    -classpath <Klassensuchpfad von Verzeichnissen und ZIP-/JAR-Dateien>
                  Eine durch : getrennte Liste mit Verzeichnissen, JAR-Archiven
                  und ZIP-Archiven zur Suche nach Klassendateien.
    -D<name>=<value>
                  Legt eine Systemeigenschaft fest
    -verbose:[class|gc|jni]
                  Aktiviert die Verbose-Ausgabe
    -version      Druckt Produktversion und beendet das Programm
    -version:<value>
                  Warnung: Diese Funktion ist veraltet und wird in einer
                  neueren Version entfernt.
                  Erfordert die angegebene Version zur Ausführung
    -showversion  Druckt Produktversion und fährt fort
    -jre-restrict-search | -no-jre-restrict-search
                  Warnung: Diese Funktion ist veraltet und wird in einer
                  neueren Version entfernt.
                  Bezieht private JREs des Benutzers in Versionssuche ein bzw. schließt sie aus
    -? -help      Druckt diese Hilfemeldung
    -X            Druckt Hilfe zu Nicht-Standardoptionen
    -ea[:<packagename>…|:<classname>]
    -enableassertions[:<packagename>…|:<classname>]
                  Aktiviert Assertions mit angegebener Granularität
    -da[:<packagename>…|:<classname>]
    -disableassertions[:<packagename>…|:<classname>]
                  Deaktiviert Assertions mit angegebener Granularität
    -esa | -enablesystemassertions
                  Aktiviert Systemassertionen
    -dsa | -disablesystemassertions
                  Deaktiviert Systemassertionen
    -agentlib:<libname>[=<options>]
                  Lädt native Agent Library <libname>, z.B. -agentlib:hprof
                  siehe auch -agentlib:jdwp=help und -agentlib:hprof=help
    -agentpath:<pathname>[=<options>]
                  Lädt native Agent Library nach vollem Pfadnamen
    -javaagent:<jarpath>[=<options>]
                  Lädt Java-Programmiersprachen-Agent, siehe java.lang.instrument
    -splash:<imagepath>
                  Zeigt Startbildschirm mit angegebenem Bild
Weitere Einzelheiten finden Sie unter http://www.oracle.com/technetwork/java/javase/documentation/index.html
~$ -Dprocilon.psf.config=/home/nutzer/.secureframework/SecureFramework/Operations.xml
bash: -Dprocilon.psf.config=/home/nutzer/.secureframework/SecureFramework/Operations.xml: Datei oder Verzeichnis nicht gefunden
~$ -jar ~.secureframework/OperationsService-1.2.0-46-jar-with-dependencies.jar
bash: -jar: Kommando nicht gefunden.

Eine Antwort erhielt ich hierauf aber nicht.

Nun schrieb ich den Support nochmals an:

Ich komme zurück auf meine Mail vom 5. 7. 2017. Wie dort bereits beschrieben, habe ich Oracles Java 8 neben OpenJDK 8 installiert und auf Standard gesetzt. Die Einzelheiten entnehmen Sie bitte der vorbezeichneten, an Sie gerichteten Mail. Dann habe ich Ihre mitgeteilten Befehle angepasst und ausgeführt. Sie funktionieren jedoch nicht.
Sie hatten sich bereit erklärt, per Fernwartung auf meinen Rechner zuzugreifen. Dieses Angebot werde ich nicht annehmen, da ich nicht möchte, dass Sie in mein Produktivsystem eingreifen. Wenn eine Veränderung stattfindet, möchte ich diese vorab und zur Reproduktion prüfen, nachvollziehen und selbst vornehmen können und zwar mit funktionierenden Befehlen.
Hierneben ist es merkwürdig, dass das beA selbst (beA Client Security) sowohl mit OpenJDK als als auch mit Oracles Java funktioniert, die Schlüsselverwaltung aber nur mit Oracles Java.

Laut Ihrem Dokument zur Schlüsselverwaltung sei diese nur mit einer einzigen Linux-Distribution, nämlich Ubuntu (14.04) möglich. Die Schlüsselverwaltung sollte jedoch mit allen gängigen Distributionen funktionieren, also mindestens neben Ubuntu (einschließlich deren Derivate) auch mit Linux Mint, Fedora, OpenSuse und Debian, zumal Ubuntu die Paketquellen Debians nutzt.

Ich schlage daher vor, funktionierende Dateien, Befehle und Dokumente auch für Linux bereitszustellen, denn zur Zeit findet sich in Ihrem Dokument lediglich ein einziger Satz zur Änderung der Systemzeit unter Linux. Sie sollten Ihr Manual nicht ausschließlich auf Windows und Mac reduzieren, damit das beA insgesamt, wie angekündigt, plattformübergreifend auch unter Linux funktioniert.

Jedenfalls ist derzeit keine Schlüsselverwaltung und insbesondere keine Änderung des Passwortes mit Debian möglich.

Werden Sie eine funktionierende Schlüsselverwaltung sowie die nötigen Befehle und Anleitungen für Debian und andere o. g. Distributionen bereitstellen?

Doch auch auf diese Anfrage antwortete der Support nicht (siehe aber das Update unten). Doch was soll’s? Die Kosten für diesen Murks trägt schließlich die Gemeinschaft der RAe.

Im Übrigen: Mit Windows wäre Dir das nicht passiert. Wechsele doch das Betriebssystem. Nein! Das werde ich nicht! Erst recht dann nicht, wenn die Entwickler mal wieder stur oder/und hilflos sind.

Nebenbei: Auch Mandanten sollen jetzt mit Rechtsanwälten vertraulich auf elektronischem Wege kommunizieren können. Als Software biete sich die neue und derzeit kostenfreie Alternative für den EGVP Classic-Bürger-Client an: der Governikus Communicator Justiz Edition. Eine Anleitung findet sich Newsletter zum besonderen elektronischen Anwaltspostfach Ausgabe 28/2017 v. 13.07.2017.

Update:

Der korrekte, anzupassende Befehl (nutzer durch den tatsächlichen Nutzernamen ersetzen; anders auch, wenn statt eines 64 ein 32-Bit-System verwendet wird) müsste laut Kommentator fleixi lauten:

java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -Dprocilon.psf.config=/home/nutzer/.secureframework/SecureFramework/Operations.xml -jar /home/nutzer/.secureframework/OperationsService-1.2.0-46-jar-with-dependencies.jar

Die Anwendung bricht jetzt zumindest nicht mehr zusammen. Allerdings sei laut Hinweis der Anwendung weder ein Kartenleser noch eine Signaturkarte angeschlossen, was nicht stimmt. Widersprüchlicherweise wird das Gerät beim Einloggen ins beA, was ebenfalls mit Java geschieht, erkannt.

Beachte dazu auch die Kommentare.

Mitterweile hat sich die procilon IT-Solutions GmbH im Auftrag der Zertifizierungsstelle der Bundesnotarkammer nochmals gemeldet und  zusammenfassend mitgeteilt,

Ubuntu 14.04 werde unterstützt, wobei keine Unterstützung weiterer Distributionen geplant sei, es aber möglich sei, dass die Signaturkartenanwendung auf anderen Distributionen mit entsprechenden Einstellungen laufe, wofür man jedoch keinen Support anbieten könne.

(Oder statt könne besser wolle? Verf.)

Die Ankündigung, das beA funktioniere auch unter Linux, ist damit Augenwischerei, wenn noch nicht einmal eine Änderung des Passwortes, geschweige denn eine komplette Schlüsselverwaltung gewährleistet ist. Schönen Dank auch!

42 comments on beA Schlüsselverwaltung unter Debian 9 Teil 2

  1. Dein Fehler liegt in der Annahme das es sich um 3 Befehle handeln. Es ist jedoch nur ein Befehl:

    java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -Dprocilon.psf.config=/home/nutzer/.secureframework/SecureFramework/Operations.xml -jar ~/.secureframework/OperationsService-1.2.0-46-jar-with-dependencies.jar

    Dann bist du zumindest n Schritt weiter

      1. Also 1. habe ich in meinen 12 Jahren Linuxnutzung noch nie einen Befehl mit – starten gesehen und 2. sieht das alles genau wie ein typischer Java Befehl aus, daher bin ich mir 100% sicher das es ein Befehl ist.

        Dann hab ich auf die schnelle über sehen das da „/home/nutzer/“ steht, was sehr wahrscheinlich nicht deinem system entspricht. „/home/nutzer/“ lässt sich korrekt durch “ ~“ ersetzen sodass der korrekte Befehl so lautet:

        java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -Dprocilon.psf.config=~/.secureframework/SecureFramework/Operations.xml -jar ~/.secureframework/OperationsService-1.2.0-46-jar-with-dependencies.jar

        Wenn du die Ausgabe von dem Befehl postest kann ich dir bestimmt weiter helfen

        1. Nutzer steht nur für meinen Nutzernamen. Der Support setzte die Bezeichnung mustermann, die ich im Befehl durch meinen tatsächlichen Nutzernamen und in diesem Beitrag mit nutzer ersetzt habe.
          Aber ich werde Deinen Befehl dennoch verwenden. Vielleicht klappt es ja. Danke für Deine Hilfe.

        2. Das klappt auch nicht. Hier, wie gewünscht, die Ausgabe:
          $ java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -Dprocilon.psf.config=~/.secureframework/SecureFramework/Operations.xml -jar ~/.secureframework/OperationsService-1.2.0-46-jar-with-dependencies.jar
          Jul 13, 2017 8:05:27 PM de.procilon.pronext.secureframework.common.log.SecureFrameworkLogger log
          INFORMATION: Operations Subsystem is starting
          Exception in thread „main“ java.lang.RuntimeException: java.io.FileNotFoundException: ~/.secureframework/SecureFramework/Operations.xml (Datei oder Verzeichnis nicht gefunden)
          at de.procilon.pronext.secureframework.operations.transport.Server.loadConfig(Server.java:400)
          at de.procilon.pronext.secureframework.operations.transport.Server.main(Server.java:311)
          Caused by: java.io.FileNotFoundException: ~/.secureframework/SecureFramework/Operations.xml (Datei oder Verzeichnis nicht gefunden)
          at java.io.FileInputStream.open0(Native Method)
          at java.io.FileInputStream.open(FileInputStream.java:195)
          at java.io.FileInputStream.(FileInputStream.java:138)
          at de.procilon.pronext.secureframework.operations.transport.Server.loadConfig(Server.java:392)
          … 1 more

          1. Ich habe die Datei cardtool.jlnp im Homeverzeichnis abgelegt. Von dort habe ich sie mit javaws cardtool.jlnp zu starten versucht, was die Anwendung mit einem Anwendungsfehler quittierte:
            CouldNotLoadArgumentException[ Angegebene Datei/URL konnte nicht geladen werden: cardtool.jlnp]
            at com.sun.javaws.Main.launchApp(Unknown Source)
            at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
            at com.sun.javaws.Main.access$000(Unknown Source)
            at com.sun.javaws.Main$1.run(Unknown Source)
            at java.lang.Thread.run(Thread.java:748)
            Caused by: java.io.FileNotFoundException: cardtool.jlnp (Datei oder Verzeichnis nicht gefunden)
            at java.io.FileInputStream.open0(Native Method)
            at java.io.FileInputStream.open(FileInputStream.java:195)
            at java.io.FileInputStream.(FileInputStream.java:138)
            at java.io.FileInputStream.
            (FileInputStream.java:93)
            at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
            … 5 more

            und

            java.io.FileNotFoundException: cardtool.jlnp (Datei oder Verzeichnis nicht gefunden)
            at java.io.FileInputStream.open0(Native Method)
            at java.io.FileInputStream.open(FileInputStream.java:195)
            at java.io.FileInputStream.(FileInputStream.java:138)
            at java.io.FileInputStream.
            (FileInputStream.java:93)
            at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
            at com.sun.javaws.Main.launchApp(Unknown Source)
            at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
            at com.sun.javaws.Main.access$000(Unknown Source)
            at com.sun.javaws.Main$1.run(Unknown Source)
            at java.lang.Thread.run(Thread.java:748)

          2. OK weiter gehts.

            Ausgabe von:

            find ~/ -name „Operations.xml“

            und Ausgabe von:

            ls -l ~/.secureframework

          3. ~$ find ~/ -name „Operations.xml“
            find: ‘/home/nutzer/.config/gsmartcontrol’: Keine Berechtigung
            ~$ sudo find ~/ -name „Operations.xml“
            [sudo] Passwort für nutzer:
            ~$ find ~/ -name „Operations.xml“
            find: ‘/home/nutzer/.config/gsmartcontrol’: Keine Berechtigung
            ~$ su
            Passwort:
            root@nutzer:/home/nutzer# find ~/ -name „Operations.xml“
            root@nutzer:/home/nutzer#

            Dann:

            $ ls -l ~/.secureframework
            insgesamt 11476
            -rw-r–r– 1 nutzer nutzer 4135 Jun 16 14:44 operations_client_license.xml.p7s
            -rw-r–r– 1 nutzer nutzer 11735051 Jun 16 14:44 OperationsService-1.2.0-46-jar-with-dependencies.jar
            drwxr-xr-x 2 nutzer nutzer 4096 Jun 16 14:44 SecureFramework

    1. die im Update genannte Zeile (egal, wie viele Befehle das sein mögen) funktioniert unter 16.04, wenn man sie als root startet. Dazu muss das Homeverzeichnis des User natürlich ausgeschrieben werden. Warum die beAClientSecurity mit Userrechten geht, ist mir ein Rätsel.
      Zuvor müssen pcscd inkl. Anhängigkeiten und der Treiber für den Kartenleser installiert sein, ich konnte meinen bei ReinerSCT runterladen.

  2. OK kann aus irgendeinen Grund nicht auf antworten klicken.

    Problem 1 bei dir ist das nirgendwo in deinem homeverzeichnis die Datei „Operations.xml“ liegt. Das heißt das entweder du was falsch installiert hast oder deren Befehl falsch ist.

    Zuletzt brauch ich noch die Ausgabe von:

    ls -l ~/.secureframework/SecureFramework/

    1. Sie liegt hier (per Dateimanager gefunden): /home/nutzer/.secureframework/SecureFramework/Operations.xml

      ls -l ~/.secureframework/SecureFramework/
      insgesamt 48
      -rw-r–r– 1 nutzer nutzer 9596 Jun 16 14:44 bnotk_ssl_truststore.jks
      -rw-r–r– 1 nutzer nutzer 4213 Jun 16 14:44 dssc-de.xml.p7s
      -rw-r–r– 1 nutzer nutzer 1850 Jun 16 14:44 dssc-de.xml.p7s.sha512.p7s
      -rw-r–r– 1 nutzer nutzer 4246 Jun 16 14:44 local-service.bnotk.de.p12
      -rw-r–r– 1 nutzer nutzer 690 Jun 16 14:44 logging.properties
      -rw-r–r– 1 nutzer nutzer 6438 Jun 16 14:44 operations-checksums.sha512.p7s
      -rw-r–r– 1 nutzer nutzer 972 Jun 16 14:44 Operations.xml

      1. Klar *kopftisch* wenn du root wirst passt ~ natürlich nicht mehr.

        Mein letzter Versuch für den Richtigen Befehl:

        java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -Dprocilon.psf.config=/home/nutzer/.secureframework/SecureFramework/Operations.xml -jar /home/nutzer/.secureframework/OperationsService-1.2.0-46-jar-with-dependencies.jar

        1. Jetzt tut sich was. Am Ende der Ausgabe blinkt jedoch der Cursor, und es geht nicht weiter:
          ~$ java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -Dprocilon.psf.config=/home/nutzer/.secureframework/SecureFramework/Operations.xml -jar /home/nutzer/.secureframework/OperationsService-1.2.0-46-jar-with-dependencies.jar
          Jul 13, 2017 9:24:46 PM de.procilon.pronext.secureframework.common.log.SecureFrameworkLogger log
          INFORMATION: Operations Subsystem is starting
          Jul 13, 2017 9:24:47 PM de.procilon.pronext.secureframework.common.log.SecureFrameworkLogger log
          INFORMATION: Load licence file: ../operations_client_license.xml.p7s
          Jul 13, 2017 9:24:47 PM de.procilon.pronext.secureframework.common.log.SecureFrameworkLogger log
          INFORMATION: Operations Subsystem is starting in CLIENT mode
          Jul 13, 2017 9:24:47 PM de.procilon.pronext.secureframework.common.log.SecureFrameworkLogger log
          INFORMATION: Set SSL-Truststore parameter with file: /home/nutzer/.secureframework/SecureFramework/bnotk_ssl_truststore.jks
          Jul 13, 2017 9:24:47 PM de.procilon.pronext.secureframework.common.log.SecureFrameworkLogger log
          INFORMATION: Request token for clientId: pnx_bundesnotarkammer_prod_client_cm
          Jul 13, 2017 9:24:49 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
          INFORMATION: Initiating Jersey application, version ‚Jersey: 1.18.1 02/19/2014 03:28 AM‘
          Jul 13, 2017 9:24:49 PM de.procilon.pronext.secureframework.common.log.SecureFrameworkLogger log
          INFORMATION: service started and bound to: https://local-service.bnotk.de:10000
          Jul 13, 2017 9:24:49 PM de.procilon.pronext.secureframework.common.log.SecureFrameworkLogger log
          INFORMATION: using remote Management server at: https://secure.bnotk.de/SecureFrameworkManagement/api

          1. OK da ich das ganze ohne Kenntnis des Programms oder der restlichen Materie (ausser Java) gemacht habe kann ich dir da jetzt leider nicht mehr weiter helfen.

            Prinzipiell gebe ich dir aber recht das das alles etwas nutzerfreundlicher gehen sollte und n support auch zeitnah antworten muss

          2. Zumindest startet jetzt die Anwendung zur Schlüsselverwaltung. Insofern scheint Dein Befehl korrekt zu sein. Vielen Dank für Deine Hilfe!
            Merkwürdig bleibt, dass der Kartenleser bei dieser Anwendung nicht erkannt wird (die Anwendung meint, es sei keiner vorhanden, was nicht stimmt), während er beim Einloggen zum beA durchaus erkannt wird. Es bleibt also Murks. Die ganze Sache ist noch zu unausgereift.
            Dass der Support des verantwortlichen Unternehmens in Wirklichkeit keiner ist, ist ein Unding.

  3. „pcscd“ installiert & gestartet? Zumindest die Bürgerkarte (Österreich) braucht das laut deren Dokumentation um mit dem Smartcardreader zu kommunizieren.

  4. Hallo,

    wenn sie mal in die Datei mit der Endung *.xml.p7s aus Ihrem .secureFrameworks Ordner gucken, müsste es den tag … geben. Ist das dort angegebene Datum noch gültig ?

    Viele Grüße

    1. Meinen Sie die operations_client_license.xml.p7s? Die lässt sich nicht so einfach mit dem Editor öffnen. Ich kann aber die ersten Zeilen lesen. Dort sind den Tags
      validity, start und end die Daten 21.04.2016 (für start) und 21.04.2080 (für end) zu entnehmen.

  5. Genau die. Schade, bei mir lag das nicht erkennen des Readers mal an einer abgelaufenen Lizenz, Ihre ist aber noch ausreichend gültig.

    Haben sie mal probiert den kompletten .secureFrameworks Ordner zu löschen ? (dieser sollte normalerweise automatisch erstellt worden sein – trotzdem ggf. lieber irgendwo eine Sicherheitskopie erstellen).

    Viele Grüße

    1. Ja, davon hatte ich auch schon in den beA-Newslettern gelesen. Aber ich meine, das betraf ein anderes Problem. Ich werde aber mal den Ordner .secureFrameworks löschen, um ihn neu erstellen zu lassen. Ich werde mich melden, falls dies die Lösung des Problems war. Ich bedanke mich!

      1. Nachtrag: Ich meine mich zu erinnern, dass sich die Nutzer überhaupt nicht ins beA einloggen konnten. Das ist vorliegend jedoch nicht so. Denn das funktioniert. Es lässt sich nur nicht das Kennwort ändern. Womit der Anbieter u. U. ein Haftungsproblem haben dürfte.

  6. Gibt es inzwischen Neuigkeiten? Ich habe derzeit das gleiche Problem, bei mir Ubuntu 18.04. mit OpenJDK, Icedtea und Firefox 61. Kartenleser und beA Clientsecurity funktionieren, die Cardtools von procilon hingegen beenden sich nach dem Fenster „Anwendung wird gestartet“ ohne erkennbare Ursache. Ist natürlich peinlich, dass der Fehler ein Jahr nach der Meldung an den Support immer noch vorhanden ist, was kein gutes Licht auf die Kompetenz des Partners der Bundesnotarkammer wirft. Gibt es eigentlich Alternativen zu diesem ProNext Zeugs? Da die beA Karte als Signaturkarte ja keine Neu- und Eigenerfindung ist, müsste doch die Schlüsselverwaltung auch mit Tools von anderen Anbietern funktionieren? Vielleicht gibt’s sogar was aus der Opensource-Welt?

    1. Es gibt keine Neuigkeiten. Am 3. 9. wird sich zeigen, ob der Client funktioniert und ob man sich einloggen kann. Dann werde ich weiter sehen. Vorher werde ich das Teil nicht anrühren. Denn ich hatte nach dem Crash aufgrund des Newsletters 11/2018 der BRAK versucht, den Client (auch probehalber unter Windows 10 mit dem Internetexplorer, da Edge nicht unterstützt wird) neu zu installieren, wobei sich die Anwendung nach dem Start schloss, ohne dass die einzelnen Anleitungsschritte nachvollzogen werden konnten.

  7. Also, bei mir (16.04) geht es. Als normaler User vorsorglich schonmal:

    xhost +

    und dann:

    java ./cardtool.jnlp

    -> Update durchlaufen lassen+ alle Instanzen von Java wieder schließen
    Dann als root anmelden und:

    java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 -Dprocilon.psf.config=/home/nutzer/.secureframework/SecureFramework/Operations.xml -jar /home/nutzer/.secureframework/OperationsService-1.5.4-3-jar-with-dependencies.jar

    Achja, bei Mate muss die Benachrichtigungsanzeige an sein. Wenn das Fensterchen im Dock erscheint, ein paralleles Terminal aufmachen und als normaler User mit:

    java ./cardtool.jnlp

    starten. Geht.

  8. Mein Versuch am letzten Wochenende führte zu der – überraschend vom Support bestätigten – Erkenntnis, dass auf der Webseite trotz gegenteiliger Behauptungen der BRAK eine alte Version des beA Clients zumindest für Linux lag; bei der Installation wies die heruntergeladene Version darauf hin, dass eine neuere vorläge – und hat mich dann immer wieder auf die Downloadseite mit der alten Version geschickt (ein interner Updateprozess, wie inzwischen allgemein üblich, scheint offenbar ATOS & Co zu überfordern) … auch die Installation lief nicht reibungslos, nach Installation der Browserzertifikate musste man ja den Browser beenden, wonach die Installation weiterlaufen sollte – Betonung liegt natürlich auf sollte, der Installationsprozess wurde nie korrekt abgeschlossen .. na, bin mal gespannt, was am Montag losgeht … btw. vielleicht kannst du auf deiner Seite ja mal eine Rubrik ERV und beA unter Linux führen, wo man die Problemchen, Lösungen etc. unserer Kollegen, die auch M$ den Rücken gekehrt haben, bündelt ..

  9. Bei mir geht auch die ClientSecurity mit Download von heute, Installer-Version 2.0.1 – die Dateien sind aber schon vom 14.2.2018.

    Allerdings kommt man in die Anmeldung (derzeit ja nur: „Registrierung für Benutzer mit eigenem Postfach“) nur mit dem Firefox, nicht mit Chromium, was mir lieber wäre.
    Das liegt offenbar an „SSL-Zertifikat hinterlegen“, das geschieht ausweislich der logs nur für Firefox, warum auch immer. Da ich nicht weiß, welches Zertifikat er da installiert hat, kann ich es auch nicht aus FF exportieren und in Chromium zu Fuß installieren.

    1. Atos Support-Antwort zum Export des Browser-Zertifikats aus Firefox und zum Import in Chrome/Chromium/Vivaldi:

      Sehr geehrte Damen und Herren,

      auf Grund des aktuell sehr hohen Anfragevolumens kann es bei der Bearbeitung Ihres Anliegens zu Verzögerungen kommen.

      Wir bitten um Ihr Verständnis.

      Mit freundlichen Grüßen
      Ihr beA-Support-Team

    2. Hi, die BRAK teilte heute mit, die SSL-Zertifikate befänden im „.beaCache“ im Home-Verzeichnis des jeweiligen Nutzers. Unter Linux wäre dies: ~/.beaCache.

      Es bleibt die Frage, wie man andere Browser außer Firefox -wie Chrome/Chromium/Vivaldi- dazu veranlassen kann, auf sie zuzugreifen.

  10. Erinnert sich noch jemand an Day of the Tentacle? So ähnlich ist es hier auch. Wer die Lösung nicht sehen will, darf hier nicht weiterlesen.

    ### Achtung, Spoiler ##################

    Also:
    zuerst gehen wir in eine Konsole und tippen ein:
    cat ~/.beaCache/bealocalhost.ssl

    Darin steht eine pin. Die kopieren wir in die Zwischenablage.

    Im Chrome gehen wir auf Zertifikate installieren und steuern das Verzeichnis an. Mit Strg-H sieht man auch die versteckten Verzeichnisse.
    Dann lassen wir uns nicht nur SSL-Zertifikate anzeigen, sondern alle Dateien und wählen die erste, die ohne Endung. Wir werden nach einem Passwort gefragt.
    Mit Strg-V fügen wir die pin ein.
    Jetzt hat er zumindest das Zertifikat. Ob es dann im beA weitergeht, habe ich noch nicht getestet.

      1. Ja, auch schon gemerkt. Dem Zertifikat wird nicht vertraut. Das sieht man, wenn man es aufklappt. Warum ihm nicht vertraut wird, steht aber nicht da.

        Vielleicht hat ja die dritte Datei damit was zu tun? Die wurde ja bisher nicht benutzt. Bei „Zertifizierungsstellen“ kann man sie theoretisch importieren und wird auch gefragt, wofür genau. Leider scheitert der Import dann daran, dass kein Zertifizierungsstelle bekannt sei, was auch immer das nun wieder heißen mag.

        Vermutlich muss man den Kumquatbaum rot anmalen oder so.
        Was sagt die BRAK dazu?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.