Hallo,

ich setze seit ein paar Jahren den Hibiscus Server ein und hatte bisher "nur" das selbsterstellte Zertifikat für den Jameica Webadmin verwendet. Nun möchte ich gerne ein Zertifikat meiner eigenen CA benutzen.

Mit dem KeyStore Explorer (macht quasi das gleiche wie OpenSSL) kann ich den "jameica.keystore" im cfg-Verzeichnis mit meinem Master-Passwort öffnen. Das Einfügen des eigenen Root-Zertifikats/Speichern des Keystores/Neustart Server verursacht noch keine Probleme. Wenn ich nun das Zertifikat "jameica" lösche und ein von meiner CA ausgestelltes Zertifikat samt privatem Schlüssel einfüge (wieder mit dem Master-Passwort gesichert und mit dem Namen "jameica")/Speichern des Keystores/Neustart Server, so startet mindestens der Jameica Webadmin nicht und ich erhalte kurz nach dem Start des Servers auch eine E-Mail, dass der Scheduler-Service gestoppt sei.

Wie kann ich nun das Zertifikat für den Jameica Webadmin austauschen, ohne die gesamte Installation zu zerschießen? Vielen Dank im Voraus!

Grüße, Martin

PS: Die Log-Ausgabe des Servers liefert folgende Fehler:

[Sat Jun 17 12:00:05 CEST 2017][ERROR][main][de.willuhn.jameica.hbci.payment.Settings.initWallet] unable to migrate wallet to AES, keeping RSA
java.lang.IllegalArgumentException: not an RSA key!
at org.bouncycastle.jcajce.provider.asymmetric.rsa.CipherSpi.engineGetKeySize(Unknown Source)
at javax.crypto.Cipher.passCryptoPermCheck(Cipher.java:1067)
at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1025)
at javax.crypto.Cipher.init(Cipher.java:1245)
at javax.crypto.Cipher.init(Cipher.java:1186)
at de.willuhn.jameica.security.crypto.RSAEngine.decrypt(RSAEngine.java:59)
at de.willuhn.jameica.security.Wallet.read(Wallet.java:267)
at de.willuhn.jameica.security.Wallet.read(Wallet.java:237)
at de.willuhn.jameica.security.Wallet.<init>(Wallet.java:87)
at de.willuhn.jameica.security.Wallet.<init>(Wallet.java:73)
at de.willuhn.jameica.hbci.payment.Settings.initWallet(Settings.java:93)
at de.willuhn.jameica.hbci.payment.Settings.<clinit>(Settings.java:58)
at de.willuhn.jameica.hbci.payment.server.SchedulerServiceImpl.start(SchedulerServiceImpl.java:87)
at de.willuhn.jameica.system.ServiceFactory.install(ServiceFactory.java:169)
at de.willuhn.jameica.system.ServiceFactory.init(ServiceFactory.java:73)
at de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:399)
at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:243)
at de.willuhn.jameica.services.PluginService.init(PluginService.java:42)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119)
at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:72)
at de.willuhn.jameica.system.Application.init(Application.java:106)
at de.willuhn.jameica.system.Application.newInstance(Application.java:90)
at de.willuhn.jameica.Main.main(Main.java:78)

[Sat Jun 17 12:00:05 CEST 2017][ERROR][main][de.willuhn.jameica.system.ServiceFactory.init] error while initializing service,
java.lang.ExceptionInInitializerError
at de.willuhn.jameica.hbci.payment.server.SchedulerServiceImpl.start(SchedulerServiceImpl.java:87)
at de.willuhn.jameica.system.ServiceFactory.install(ServiceFactory.java:169)
at de.willuhn.jameica.system.ServiceFactory.init(ServiceFactory.java:73)
at de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:399)
at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:243)
at de.willuhn.jameica.services.PluginService.init(PluginService.java:42)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119)
at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:72)
at de.willuhn.jameica.system.Application.init(Application.java:106)
at de.willuhn.jameica.system.Application.newInstance(Application.java:90)
at de.willuhn.jameica.Main.main(Main.java:78)
Caused by: java.lang.NullPointerException
at de.willuhn.jameica.hbci.payment.Settings.initWallet(Settings.java:104)
at de.willuhn.jameica.hbci.payment.Settings.<clinit>(Settings.java:58)
... 12 more

[Sat Jun 17 12:00:05 CEST 2017][ERROR][main][de.willuhn.jameica.plugin.PluginLoader.init] unable to init plugin hibiscus.server: Plugin "hibiscus.server" wurde aufgrund eines Fehlers bei der Initialisierung deaktiviert.
Fehlermeldung: java.lang.ExceptionInInitializerError

[...]

[Sat Jun 17 12:00:06 CEST 2017][INFO][pool-1-thread-1][de.willuhn.jameica.messaging.NamedConcurrentQueue.deliver] error while processing message
java.lang.NoClassDefFoundError: Could not initialize class de.willuhn.jameica.hbci.payment.Settings
at de.willuhn.jameica.hbci.payment.WebAdminDeployer.getUserRealm(WebAdminDeployer.java:62)
at de.willuhn.jameica.webadmin.deploy.AbstractWebAppDeployer.deploy(AbstractWebAppDeployer.java:46)
at de.willuhn.jameica.webadmin.messaging.DeployMessageConsumer.handleMessage(DeployMessageConsumer.java:72)
at de.willuhn.jameica.messaging.NamedConcurrentQueue.deliver(NamedConcurrentQueue.java:246)
at de.willuhn.jameica.messaging.NamedConcurrentQueue.access$000(NamedConcurrentQueue.java:26)
at de.willuhn.jameica.messaging.NamedConcurrentQueue$1.run(NamedConcurrentQueue.java:81)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Ebenso kann der Jameica Server seine (verschlüsselten) Backups nicht lesen.

Das Zertifikat kann nicht ausgetauscht werden. Es ist ja auch nicht nur dafuer da, den Web-Service per HTPS anzubieten, sondern ist die integrale Basis fuer saemtliche Verschluesselungsfunktionen in Jameica - der Master-Key, auf dem andere Verschluesselungsfunktionen aufbauen. Damit werden zum Beispiel zu speichernde Passwoerter verschluesselt gespeichert. Siehe auch http://www.willuhn.de/wiki/dok…geschuetzt
Daher gibt es dieses System-Zertifikat auch nicht nur im Payment-Server sondern in jeder Jameica-Installation (also auch Desktop).

Das System-Zertifikat zu ersetzen, ist ungefaehr so, als wuerde man versuchen, sein Auto mit der Fernbedienung von einem anderen zu oeffnen.

Wenn es dir darum geht, dass der Webservice ein eigenes SSL-Zertifikat verwendet, dann muesstest du HTTPS in jameica.webadmin abschalten, den Dienst an 127.0.0.1 binden und dann z.Bsp. über einen vorgeschalteten Apache mit mod_proxy und "ProxyPass" bzw. "ProxyPassReverse" erreichbar machen und dort dann die gewuenschten Zertifikate hinterlegen.

https://github.com/willuhn/hib…properties



Update: Du hast Glück. Ich hatte erst kürzlich im Nightly-Build die integrierte Jetty-Version aktualisiert und in dem Zusammenhang auch den Alias-Namen des Keystore-Entries explizit angegeben, welcher fuer den HTTPS-Teil verwendet werden soll. Diesen Alias-Namen habe ich gerade eben noch konfigurierbar gemacht. Ist ab morgen im Nightly-Build des Payment-Servers. Siehe

https://github.com/willuhn/jam…d0f1864f10

Damit kann dann das HTTPS-Zertifikat unabhaengig vom Jameica-Systemzertifikat konfiguriert werden. Fuege zum Keystore also ein weiteres Schluesselpaar mit einem anderen(!) Alias-Namen als "jameica" und trage diesen Alias-Namen dann in ~/.jameica/cfg/de.willuhn.jameica.webadmin.Plugin.properties ein:

Vielen Dank schon mal, probiere ich gleich noch aus.

Wenn ich einmal eine Nightly installiere... komme ich dann später probemlos wieder auf die Release-Version zurück, wenn ich auf Probleme stoße?

Ja, das geht problemlos.

So, ich bin endlich dazu gekommen die Nightly auszuprobieren. Zunächst verweigerte der Server den Start, da der Paramter -f <Datenverzeichnis> für die Angabe des Datenverzeichnisses nicht beachtet wurde.

Ich habe dann mal testweise mal das cfg-Verzeichnis nach c:\Users\admin\.jameica\cfg kopiert, nun startet der Server schon mal wieder.

In den Keystore habe ich mit gleichem Kennwort das Zertifikat mit privatem Schlüssel als Alias "webcert" sowie das Root-Zertifikat (ohne privaten Schlüssel ) eingefügt und in der de.willuhn.jameica.webadmin.Plugin.properties als neue Zeile

eingefügt. Der Server startet, aber wieder mit dem selbstsignierten Zertifikat.

Dieser Fehler sollte nicht auftreten. Beim Start des Servers sollte hier auch angezeigt werden, was konkret die Ursache fuer den Fehler war. Oft ist der Fehler, dass der Benutzer entweder im angegebenen Benutzerverzeichnis keine Schreibrechte existierten oder dass sich das angegebene Benutzerverzeichnis innerhalb des Jameica-Programmordners befindet (was nicht zulaessig ist). Siehe http://www.willuhn.de/wiki/dok…nis_nutzen



Dann wurde der Parameter nicht gelesen und der Server ist wieder auf den Default-Alias zurueckgefallen. Eventuell hast du die Aenderung an der falschen de.willuhn.jameica.webadmin.Plugin.properties vorgenommen (im Zusammenhang mit dem Benutzer-Verzeichnis-Problem oben).

Habs heut nochmal versucht, trotz zu gestern identischer Kommandozeile startet nun auch Hibiscus-Server 2.7.0 mit dem angegebenen Konfigurationsverzeichnis, kann aber nicht nachvollziehen, warum es gestern nicht funktioniert hat.
Kommandozeile zum Starten von Hibiscus-Server 2.6.9: d:\Hibiscus-Server-2.6.9\jameicaserver.exe -p <pass> -f D:\hibiscus-daten
Kommandozeile zum Starten von Hibiscus-Server 2.7.0: d:\Hibiscus-Server-2.7.0\jameicaserver.exe -p <pass> -f D:\hibiscus-daten

Mit dem Key Store Explorer habe ich dann noch etwas am Keystore rumgespielt (natürlich mit Backup). Der Aliasname des Zertifikats, welcher ja in der de.willuhn.jameica.webadmin.Plugin.properties eingetragen wird, muss mit dem CN des Zertifikats übereinstimmen. Zuvor hatte ich zwar den gewünschten CN im Zertifikat, der Alias lautete aber "webcert". Der Eintrag im Keystore darf neben Cert+Key auch das ausstellende Stammzertifizierungsstellenzertifikat enthalten.

Nachtrag: Ich habe nun in der zweiten Instanz auf meinem Server (gleiches Anwendungsverzeichnis, abweichendes Datenverzeichnis, abweichender Webadmin-Port) ebenfalls den Keystore bearbeitet und noch ein paar Besonderheiten festgestellt: bei bestimmten Aliasnamen scheint der Keystore in anderer Reihenfolge verarbeitet zu werden - dann wird das neue Web-Zertifikat genutzt, auch wenn KEIN Eintrag in der de.willuhn.jameica.webadmin.Plugin.properties vorgenommen wird.
- Der Keystore enthält nun zwei Zertifikate mit privatem Schlüssel (das selbstsignierte Zertifikat und das von meiner CA ausgestellte Zertifikat)
- sämtliche Änderungen am Keystore habe ich mit dem "Key Store Explorer" vorgenommen (keine Ahnung, ob das einen Einfluss auf das Verhalten hat)
- Das Zertifikat (ausgestellt von meiner CA) ist immer das gleiche, erhält nur einen anderen Alias
- Das neue Zertifikat im Keystore wird benutzt, wenn der Alias "aaa" lautet. Verwende ich den Hostnamen, der in meinem Zertifikat angegeben ist (gehört der hierher oder geheim halten?), so funktioniert es ebenfalls ohne Eintrag.
- Setze ich den Eintrag in der de.willuhn.jameica.webadmin.Plugin.properties setze, so wird ebenfalls mein Zertifikat verwendet (CN=Alias=Config-Eintrag; ich habe nicht geprüft, ob ein anderer CN ein anderes Verhalten zeigt)
- Lautet der Alias "bbb" (alphabetisch vor dem ersten Zertifikat), "ddd", "hibiscus" (alphabetisch zwischen den ersten drei Zertifikaten ohne privaten Schlüssel und dem Zertifikat mit privatem Schlüssel), "webcert" oder "zzz" (alphabetisch nach allen anderen Zertifikaten), so wird das selbstsignierte Zertifikat verwendet.

Ich habe den Keystore-Alias nun drei Runden lang in aaa --> bbb --> ddd --> <CN> --> webcert --> zzz geändert, jeweils den Hibiscus-Server neugestartet und erhalte immer das gleiche Ergebnis (ausprobiert im Internet Explorer, sowohl Seite mit Strg+F5 neu geladen als auch Browser beendet und Seite erneut aufgerufen)

Das waere mir neu. Dafuer sind doch die Alias-Namen da - um im Keystore einen vom CN unabhaengigen Identifier zu haben.
Das System-Zertifikat von Jameica selbst (also das mit dem Keystore-Alias "jameica") verwendet als CN ja auch nicht "jameica" sondern den Hostnamen des Systems, auf dem es erstellt wurde.

Die Reihenfolge der Zertifikate im Keystore ist nicht spezifiert. Und da sie per eindeutigem Alias-Namen adressiert werden, gehe ich davon aus, dass die Java-interne Implementierung, welche den Keystore liest, eine Datenstruktur vom Typ Hashtable verwendet und damit eine Reihenfolge in dem Sinne gar nicht existiert. Heisst: Wenn kein Zertifikat explizit angegeben ist, wird einfach das erste verwendet, welches gerade gefunden wird.

http://git.eclipse.org/c/jetty…tty-8#n274




Hast du die Zeile in der Datei komplett entfernt oder nur den Wert? In letzterem Fall waere dann explizit ein leerer Alias angegeben. Und damit wird einfach der erste gefundene verwendet.

Update: Ich habe mir jetzt nochmal den Quellcode der SslContextFactory von Jetty genau angeschaut. Ich glaube, das Setzen des Alias bringt gar nichts. Wenn ich das richtig verstehe, waehlt Jetty aus den verfuegbaren Zertifikaten einfach das aus, dessen CN am besten passt: http://git.eclipse.org/c/jetty….3.x#n1707

Ich entferne daher das Feature zum Setzen des Alias wieder aus Jameica.

... welcher ja auch nicht zwangsläufig der DNS-/Hostname sein muss, mit dem der Server angesprochen wird (die verschiedenen Dienste auf der Maschine spreche ich mit verschiedenen DNS-Namen über CNAMEs an - falls ich einen der Dienste mal umziehen möchte und muss so an den Clients keine Änderungen vornehmen).


Dann vielleicht die Reihenfolge anhand alphabetisch sortiert Hashwerte der Aliase? Hatte ja verschiedene Aliase durchprobiert, nur bei zwei Test-Aliasen wurde das von mir hinzugefügte Zertifikat verwendet. Okay, ich versuch nicht drüber nachzudenken.

Ich habe die Zeile komplett entfernt.

Das Zertifikat wird doch beim Start des Webservers ausgewählt (wenn schon nicht in einer Konfiguration eintragen) und dann beim Start der Verbindung nur noch an den Client ausgeliefert - zumindest funktionierts beim IIS und auch bei Firewalls mit Reverse-Proxy so (würden mehrere Dienste über einen Port angeboten, würde dieser erst nach initialem Verbindungsaufbau per Hostheader identifiziert und dann bräuchte es ja ein SAN-Zertifikat für alle Hostnamen oder gleich mit Wildcard).

Beim XMPP-Server Openfire wird es mit mehreren Keystores gelöst - wäre ein separater Keystore für den Webadmin dann nicht einfacher zu implementieren? Beim ersten Start könnte dann vom Webadmin-Plugin einfach eine Kopie des vorhandenen Keystore oder gleich ein komplett neuer Keystore erzeugt werden. So könnte dann auch der weniger versierte Nutzer bei einem Umzug/Umbenennen des Servers einfach den Web-Keystore löschen und neu anlegen (lassen).

Trotzdem vielen Dank für deine Mühe und vielleicht klappt es ja mit einer späteren Jetty-Version besser

Egal. Es spielt keine Rolle mehr. In der jetzigen Implementierung des Jameica-Plugins kann man kein Zertifikat explizit angeben. Es wird mehr oder weniger zufaellig das erste passende von Jetty verwendet.



Fuer die Keystore-Eintraege ist meines Wissens nach keine Reihenfolge spezifiziert. Selbst wenn irgendeine Sortierung erkennbar ist, kann man sich nicht drauf verlassen.



Die Tatsache, dass das mit dem Zertifikat bei dir - je nach verwendetem Alias-Namen - bisweilen klappte, hatte nichts mit der Implementierung von mir zu tun, bei der man den Alias-Namen in der Config angeben konnte. Es war blanker Zufall. Der in der Config angegebene Alias-Name wird jedenfalls definitiv ignoriert. Ich habe es im Quellcode von Jetty ueberprueft. Von daher: Bastel dir das mit den Alias-Namen passend so hin, dass das von dir gewuenschte verwendet wird. Mehr kann ich im Moment leider nicht tun.

Ich moechte hier eigentlich auch keinen weiteren Aufwand investieren. Es gibt eigentlich wichtigere Themen in Hibiscus zu tun.