Warum muss ich ein SSL cert immer manuell hinzufügen?

[Fohnbit]

Hallo!

Ich greife mit div. Codezeilen auf meinen eigenen öffentlichen Server zu:

https://demo.com

Dort ist ein vom provider Wildcard Zertifikat, das natürlich gültig ist.

Aber wenn ich das zertifikat nicht manuell im keystore hinzufüge, erhalte ich die Probleme mit dem cert.

Ich kann ja von jedem Browser die Webseiten öffnen. Warum muss ich also jedes Jahr meinen keystore aktualisieren?

Danke!

 

[LimDul]

Zertifikate haben in der Regel Certification Chain. Darüber wird geprüft, ob das Zertifikat gültig ist und vertrauenswürdig ist.

Sprich, das Zertifikat für die Webseite ist von irgendeine Certificat Authority unterschrieben, diese ggf. auch wieder von einer usw. bis man einem "Root"-Zertifikat angekommen ist. Wichtig ist, dass irgendeins dieser Zertifikate als Vertrauenswürdig anerkannt ist. Dazu sind im Browser in der Regel alle relevanten Root-Zertifikate hinterlegt und - das ist wichtig - werden auch regelmäßig aktualisiert.

Analog muss es im Java Keystore hinterlegt sein. Das heißt, die Gründe, dass es nicht klappt wird sein, dass das Root Zertifikat nicht hinterlegt ist. Dafür kann es verschiedene Gründe geben:

• Alte Java Version wo dieses Root-Zertifikat nicht hinterlegt ist
• Es ist ein nicht ganz so bekanntes Root Zertifikat, was im Java Keystore nicht drin ist

...

Dementsprechend ist saubere Lösung nicht das konkrete Webseiten Zertifikat zu hinterlegen, sondern das entsprechende Root Zertifikat. Ggf. mal googlen, warum das im Java Key Store nicht hinterlegt ist.

 

[Oneixee5]

Ich greife mit div. Codezeilen auf meinen eigenen öffentlichen Server zu:
https://demo.com
Dort ist ein vom provider Wildcard Zertifikat, das natürlich gültig ist.

Soviel dazu:

 

[Robert Zenz]

Ich greife mit div. Codezeilen auf meinen eigenen öffentlichen Server zu:
https://demo.com
Dort ist ein vom provider Wildcard Zertifikat, das natürlich gültig ist.

Naja, nicht ganz:

Websites prove their identity via certificates. Waterfox does not trust this site because it uses a certificate that is not valid for demo.com. The certificate is only valid for the following names: *.idg.com, *.agreenbot.com, *.architectwithconfidence.com, *.cecexchange.com, *.cio.co.nz, *.cio.co.uk, *.cio.com.au, *.cio.in, *.cio.nl, *.cioleadership.com, *.cioperspectives.com, *.computerworld.co.nz, *.computerworld.com.au, *.computerworld.in, *.computerworld.nl, *.computerworlduk.com, *.cso.com.au, *.csoonline.com.au, *.csoonline.in, *.csoperspectives.com, *.csoseminars.com, *.cwcxo.com, *.cxo.nl, *.darwinmag.com, *.futureitidg.com, *.games.net, *.ibmsubnet.com, *.idgconnect.com, *.idgneon.com, *.itwhitepapers.com, *.javaworld.org, *.linuxworld.com, *.maccentral.com, *.macuser.com, *.nwfusion.com, *.nww.com, *.techdispenser.com, *.technologybriefcase.com, *.techworld.com, *.techworld.com.au, *.thestandard.com, *.wearablog.com, agreenbot.com, architectwithconfidence.com, cecexchange.com, cio.co.nz, cio.co.uk, cio.com.au, cio.in, cio.nl, cioleadership.com, cioperspectives.com, computerworld.co.nz, computerworld.com.au, computerworld.in, computerworld.nl, computerworlduk.com, cso.com.au, csoconfab.com, csoconference.com, csoonline.com.au, csoonline.in, csoperspectives.com, csoseminars.com, cwcxo.com, cxo.nl, darwinmag.com, futureitidg.com, games.net, ibmsubnet.com, idgconnect.com, itwhitepapers.com, javaworld.org, linuxworld.com, maccentral.com, macuser.com, nwfusion.com, nww.com, techdispenser.com, technologybriefcase.com, techworld.com, techworld.com.au, thestandard.com, wearablog.com, www.computerworld.in, www.csoconfab.com, www.csoconference.com

Also das Zertifikat ist gueltig, aber nicht fuer die Domaene "demo.com". Das ist so als wuerdest du mit einem Zertifikat fuer "somedumbdomain.com.tw" versuchen einen Server hinter der Domaene "google.com" zu betreiben, das darf nicht einfach so durchgelassen werden.

Aber wenn ich das zertifikat nicht manuell im keystore hinzufüge, erhalte ich die Probleme mit dem cert.

Ich nehme mal an du verwendest den Java oder Apache HTTP-Client, in beiden Faellen musst du die TLS-Verbindung so konfigurieren dass sie dieses Zertifikat annimmt. Entweder du konfigurierst die TLS-Verbindung so dass sie alle Zertifikate akzeptiert (weniger cool) oder so das sie auch dieses Zertifikat akzeptiert.

 

[LimDul]

Ich ging jetzt davon aus, dass das nicht die echte Domain ist muss ich gestehen

 

[Robert Zenz]

Ich ging jetzt davon aus, dass das nicht die echte Domain ist muss ich gestehen

War ich auch am ueberlegen, aber wieso schreibt man es sonst hin?

 

[dua]

demo.com legt auch so gar nicht die Vermutung nahe, es könnte sich um ein Beispiel handeln...

 

[Fohnbit]

Hallo an alle!

Danke erstmal und sorry für die Verwirrung. Dachte demo.com sei eindeutig, das es sich um ein Beispiel handelt. Hab gar nicht geschaut ob es die Domain überhaupt gibt

Root Zertifikat werde ich prüfen. Auch in Eclipse am Windows PC habe ich das Problem.
Wird mit Java ein allgemeiner keystore denn mitgeliefert?

 

[LimDul]

Ja, generell ist einer dabei. (Siehe z.B. https://www.baeldung.com/java-keystore für Infos).

Welche Java-Version ist den installiert? (Und zwar die genaue, nicht Java 8 sondern z.B. OpenJDK Java 8u123)

 

[Fohnbit]

Ich betreibe meine kleinen Programme auf kleinen ARM Linux PCs und Standard Windows 10 Geräten:

ARM Linux mit Debian 9.12

java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) Client VM (build 25.161-b12, mixed mode)

Windows PC:

java version "1.8.0_371"
Java(TM) SE Runtime Environment (build 1.8.0_371-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.371-b11, mixed mode)

 

[LimDul]

Die Linux Version ist bereits über 5 1/2 Jahre alt. Die würde ich mal dringend updaten.
Die 371 ist aktuell - ich würde da aber auch eher auf eine aktuelle OpenJDK Version setzen.

Java 8 ist generell mittlerweile mehr als Veraltet - das gerne mal alles auf ein zeitgemäßes JDK (z.B. openJDK 21 oder https://adoptium.net/de/) aktualisieren.

 

[KonradN]

Also die Frage ist immer, was genau Du machst.

Zertifikat Grundlagen:

• Du hast eine Zertifikats-Kette: Root -> Intermediate -> Dein Zertifikat (Oder länger)
• Dem Zertifikat wird vertraut, wenn der Kette vertraut wird bis zu einem Punkt, dem Du vertraust.

Dann ist die Frage, was genau Du mit dem Zertifikat machst. Ich gehe mal von SSL aus.
SSL Grundlage:

• Der Client fragt beim Server nach: "Hey - gib mir Dein Zertifikat"
• Der Server gibt dann das / die Zertifikate zurück. Und das ist dann in der Regel: Intermediate & eigenes Zertifikat
• Der Client prüft das dann:

a) ist das Zertifikat für den Host gültig? Also wenn Du auf https://1.2.3.4 zugreifst und das Zertifikat ist für demo.org, dann passt es nicht - selbst wenn demo.org zu 1.2.3.4 aufgelöst würde!
b) ist das Zertifikat gültig?
c) Wird dem Zertifikat vertraut? -> Nein (bzw. ja, wenn Du es manuell hinzu gefügt hast, dann wäre hier Schluss!)

d) Ist es von einem Zertifikat signiert? Hier ist jetzt wichtig: Das Zertifikat muss bekannt sein. Und es gibt keinen Automatismus für Zertifikatdownloads oder so. Also keine Zentrale Stelle, wo alle Zertifikate liegen... Da das Zertifikat aber mitgegeben wurde, ist es bekannt und das Zertifikat kann jetzt auch geprüft werden:
e) Ist das Zertifikat gültig?
f) Wird dem Zertifikat vertraut? -> Nein. Intermediate Zertifikate werden nicht vertraut. Das ist nur für root Zertifikate üblich.

g) Ist das Zertifikat Signiert? -> Ja. Ist es bekannt? Ja (denn das ist jetzt das root Zertifikat)
h) Ist das root Zertifikat gültig? Ja (hoffentlich)
i) Wird dem Zertifikat vertraut? Ja - ist ja ein vertrautes Root Zertifikat! Damit wird dem Intermediate Zertifikat vertraut und weil dem vertraut wird, wird auch dem Server Zertifikat vertraut.

Das ist also die (vereinfachte) Kette, die Du prüfen solltest. Und ein Webbrowser sollte das Zertifikat anzeigen und klar sagen, ob dem Zertifikat vertraut wird.
Wenn das Zertifikat korrekt angezeigt wird, aber dem Zertifikat nicht vertraut wird, dann fehlt in der Regel das Intermediate Zertifikat oder dem Root Zertifikat wird nicht vertraut.

Hier ist also wichtig, dass Du dies richtig angehst:

Wenn die Zertifikate von einer vertrauenswürdigen Authority ausgegeben wurden, dann ist das root Zertifikat hinzu zu fügen. Das gilt sehr lange und wird in der Regel auch automatisch aktualisiert. Also z.B. Microsoft aktualisiert diese in Windows, in Java werden diese aktualisiert, ....
Damit dies funktioniert musst Du aber das / die Intermediate Zertifikate zusammen mit Deinem Zertifikat ausgeben.

Nur wenn der CA nicht vertraut wird, dann vertraust Du dem Zertifikat selbst. Und dann musst Du das immer aktualisieren. Hier ist dann ggf. zu überlegen, ob man nicht seine eigene CA machen will (falls man mehrere Systeme / Server hat). Dann kannst Du einmal Deiner CA vertrauen (die ist dann x Jahre gültig. Also einmal dem Zertifikat vertrauen und gut ist!) Mit dem CA Zertifikat erstellst Du Dir dann ein Intermediate Zertifikat und danach kommt das CA Zertifikat in den Firmentresor! Und dann kannst Du mit dem Intermediate weitere Zertifikate unterschreiben. Da kannst Du dann Laufzeiten haben, wie Du willst. Du kannst z.B. die vorhandenen Tools nutzen, um da automatisch lokal die Zertifikate zu erneuern. Dann kann ein Zertifikat z.B. nur 3 Monate gültig sein.

Edit: Evtl. noch der wichtige Hinweis: Ich habe eine stark vereinfachte Sicht gezeigt. Das ist also keine ganz umfängliche Darstellung der Abläufe und auch keine ganz exakte. So sind auch Dinge wie Widerruf und so nicht behandelt. Die Thematik ist also deutlich komplexer als hier dargestellt aber für die Fehlersuche sollte diese vereinfachte Darstellung helfen.

 

[mihe7]

Oops, das hat sich jetzt mit dem Beitrag von @KonradN überschnitten. Daher als Ergänzung zu sehen: man kann auch mal mit ssllabs (https://www.ssllabs.com/ssltest/) testen, ob der Server richtig konfiguriert ist. Hier sieht man dann auch, welche Zertifikate/Zertifikatsketten der Server an den Client liefert.

 

[Fohnbit]

Vielen Dank für die ausführliche Antworten!

Die kleinen Linux Rechner updaten ist sicher eine gute Idee. Meine ich hatte da einmal Schwierigkeiten, aber ich teste das heute noch einmal.
Das wäre demnach für ein BeagleBone ARM MiniPC das korrekte? JDK würde ich nehmen.


Mein SSL sieht so aus:

 

[mihe7]

Gut, dann kannst Du schon mal davon ausgehen, dass es mit der Certificate Chain keine Probleme gibt.

Das wäre demnach für ein BeagleBone ARM MiniPC das korrekte? JDK würde ich nehmen.

Exakt. Nachtrag: bni mir allerdings nicht sicher, wg. 64/32 Bit...

 

[dua]

Mein SSL sieht so aus

Mein SSL-Report sieht so aus:



Der Test hat aber sehr lange gedauert und ich musste ihn nach einer Zeit abbrechen. "Nur" 90 % bei Key Exchange und bei Ciper Strength kann ich mir nicht erklären, ich ging eigentlich A+ aus ...

Unable to perform this test due to an internal error. INTERNAL ERROR: test.drownattack.com

vielleicht liegts ja auch daran, dass kein A+...

 

[mihe7]

Der Test hat aber sehr lange gedauert

Ja, da scheint wohl drownattack.com down zu sein.

"Nur" 90 % bei Key Exchange und bei Ciper Strength kann ich mir nicht erklären

Das sieht bei mir auch so aus. Bzgl. Key Exchange bekommt man die 90 %, wenn der DH Parameter oder Key < 4096 Bit lang ist. Die Cipher-Strength ist ein Durchschnitt: wenn der Server mind. 128-Bit-Verschlüsselung verlangt, gibt es eine Score von 80 %, das ergibt zusammen mit den 100 % für die ebenfalls angebotene 256-Bit-Verschlüsselung im Schnitt 90 %.

vielleicht liegts ja auch daran, dass kein A+...

Ne, ich bekomme ein A+.

 

[dua]

Danke für die Erklärung Also ist dein Cert "sicher sicher" (doppelt). 🤣 Das heißt, ein Angreifer könnte nicht mitlesen...

 

[KonradN]

Danke für die Erklärung Also ist dein Cert "sicher sicher" (doppelt). 🤣 Das heißt, ein Angreifer könnte nicht mitlesen...

Was? Bei SSL kann ein Angreifer generell nicht mitlesen bei dem https Traffic.

A+ bedeutet lediglich, dass der Server HSTS aktiviert hat, d.h. in ganz einfachen Worten ausgedrückt: Der Server sagt dem Client, dass er nur über sichere Verbindungen erreichbar ist und dass der Client immer sichere Verbindungen zum Server erzwingen soll..

How do I get A+ rating in SSLLabs? - SSL Certificates - Namecheap.com

An ‘A’ grade should be shown by default when a valid SSL certificate with all Intermediate CA certificates is installed.

The coveted “A+” grade on SSLLabs can be achieved by enabling of HSTS policy on a server. HSTS technique is explained here. In a nutshell, HSTS is a mechanism enabling web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections as indicated in RFC 6797.

Das hat also erst einmal nichts mit der Sicherheit des Zertifikats zu tun oder so sondern rein mit der Konfiguration des Servers. Der Client kommt also nicht auf die Idee, eine http Verbindung aufzubauen.

 

[dua]

Was? Bei SSL kann ein Angreifer generell nicht mitlesen bei dem https Traffic.

Bleiben wir doch korrekt: Einem MITM wird es erschwert, mitzulesen.

nichts mit der Sicherheit des Zertifikats zu tun oder so sondern rein mit der Konfiguration des Servers. Der Client kommt also nicht auf die Idee, eine http Verbindung aufzubauen.

Das ist falsch. Mein Server ist so konfiguriert, dass keine http-Verbindung möglich ist. Dennoch hat er mir nicht A+ gegeben.

 

[dua]

Btw. HSTS ist übrigens erst einmal nur ein einfacher Header - hat also nicht mit einer höheren Sicherheit zu tun ... Aber wir kennen das ja von Dingen, die gerade hip sind ...

 

[dua]

Ist doch ein bisschen so, wie mit dem Nutri-Score... Ob ich wo wirklich länger lebe, wenn ich immer B anstatt C esse?? 🤣

 

[KonradN]

Bleiben wir doch korrekt: Einem MITM wird es erschwert, mitzulesen.

Mir fehlt zu dieser Aussage weiterhin jegliches Argument.

Das ist falsch. Mein Server ist so konfiguriert, dass keine http-Verbindung möglich ist. Dennoch hat er mir nicht A+ gegeben.

Auf dem Link findet sich die Dokumentation incl. weitergehender Links. Denen kannst Du nachgehen. Wenn du meinst, dass da etwas falsches steht, dann kannst Du es gerne berichtigen.

Bezüglich Deines Servers kann ich natürlich keine Aussage treffen. Im Augenblick würde ich einfach sagen, dass Du schlicht etwas falsch gemacht hast. Evtl. gibt es ja auch die Möglichkeit, Details anzufordern? So Checks bieten in der Regel auch genaue Dokumentationen, was wie getestet / bewertet wurde.

Dem kann man im Detail nachgehen.

 

[dua]

Mir fehlt zu dieser Aussage weiterhin jegliches Argument.

Ja, Firefox hat Unrecht, nur Konrad hat recht.

 

[KonradN]

Wenn Du die Quelle "Firefox" etwas genauer ausführen könntest. So sind Deine Aussagen einfach nur Zeitverschwendung da ohne wirklichen Informationsgehalt.

Und dann dieses Kindergarten-Niveau. Es geht nicht um eine Aussage von mir sondern z.B. von der Seite von SSL Labs:
How do I get A+ rating in SSLLabs? - SSL Certificates - Namecheap.com

Und dem gegenüber stehen Aussagen von Dir ohne wirkliche Aussagen. Ja, bei Deinem Server mit Deinem Zertifikat ist es dann kein A+ das hat der Check ganz offensichtlich gezeigt. Das liegt aber - so ich die Beschreibung richtig verstanden habe - einfach nur an der Konfiguration und eben nicht an dem Zertifikat. Aber das ist natürlich nur eine Vermutung und da Du keine Informationen liefern willst, wird man Dich da auch nicht weiter führen können.

Ist für mich ok, da es a) nicht mein Server ist und b) mir es absolut egal ist, wie da bei Dir etwas bewertet wird. Daher ist das hier einfach zu dem typischen Punkt "Der kleine Tobias will aus dem Bällespieleparadies abgeholt werden" gekommen und da folgt meist nur noch die Accountsperre aber eigentlich nie eine sinnvolle Diskussion.

 

[dua]

Soll ich die relevanten Textstellen noch farblich hervorheben oder genügt das schon?

Daher ist das hier einfach zu dem typischen Punkt "Der kleine Tobias will aus dem Bällespieleparadies abgeholt werden" gekommen und da folgt meist nur noch die Accountsperre aber eigentlich nie eine sinnvolle Diskussion.

Wieso hast du dich damals eigentlich hier wieder angemeldet? Ich meine, du wolltest doch deinen Account löschen lassen ...

 

[KonradN]

Also nur um noch einmal das Thema deutlich zu machen:

Es ging um A vs. A+ Zertifikat - denn darauf bist Du ja etwas herum geritten und da Aussagen gebracht a.la.

Also ist dein Cert "sicher sicher" (doppelt)

Und bei der Unterscheidung zwischen A und A+ spielt das Zertifikat selbst keine Rolle mehr - zumindest wenn man die Dokumentation von SSL Lab anschaut.

Was Du mit mit Deinem Bildschirmfoto diesbezüglich sagen willst, verstehe ich nicht. Was willst Du damit sagen?

Ich meine, du wolltest doch deinen Account löschen lassen ...

Das war ein Versuch, dass Du Forentroll nicht ständig auf mich reagierst. Aber so wie es trivial ist, Dich in Deinen Posts sofort zu erkennen ist es auch möglich, meine Erklärungen zu erkennen. Daher war es ein Versuch wert. Aber mit so einem Troll kann ich gut leben - wie Du hier erkennen kannst. Zumal es immer sehr lustig ist, wenn Du mit irgendwelchen einfachen Fragen um die Ecke kommst ... wo Du doch unfehlbar bist und hier alle keine Ahnung haben und so ... )

 

[dua]

Ich hab heute aber keinen Zeit für Kindergartenspiele

Das Zitat ist aus dem FF. Dort steht, vereinfacht, dass es keine 100 %ige Sicherheit geben kann.

Also, kein System ist sicher. Dem willst du doch hoffentlich nicht wiedersprechen oder?

Aber Wurst, das hat doch gar nix mehr mit der Eingangsfrage zu tun.

 

[dua]

wiedersprechen

widersprechen, meinte ich ... Das Handy-Wörterbuch ist auch nicht mehr das, was es mal war ...

Noch etwas zum Thema ... Wenn man unbedingt eine A+ haben möchte, sollte man in der Webserverkonfiguration das HSTS-Feature aktivieren ... hab's vorhin mal getestet (das ist auch recht billig zu bewerkstelligen, bei mir war es einfach ein zusätzlicher Zweizeiler ...).

 

[KonradN]

Also, kein System ist sicher. Dem willst du doch hoffentlich nicht wiedersprechen oder?

Das war nie das Thema und das habe ich nie behauptet.

Noch etwas zum Thema ... Wenn man unbedingt eine A+ haben möchte, sollte man in der Webserverkonfiguration das HSTS-Feature aktivieren ... hab's vorhin mal getestet (das ist auch recht billig zu bewerkstelligen, bei mir war es einfach ein zusätzlicher Zweizeiler ...).

Damit hast Du dann jetzt doch verstanden, worauf ich in #19 hingewiesen habe und was im Link von SSL Labs steht. Wozu brauchten wir die Posts [11-27]? Aber das vertiefen wir jetzt bitte nicht.

 

[Marinek]

https://i.imgur.io/8tXJKlq_d.webp?maxwidth=640&shape=thumb&fidelity=medium

 

[Fohnbit]

@

Also die Frage ist immer, was genau Du machst.

Zertifikat Grundlagen:

• Du hast eine Zertifikats-Kette: Root -> Intermediate -> Dein Zertifikat (Oder länger)
• Dem Zertifikat wird vertraut, wenn der Kette vertraut wird bis zu einem Punkt, dem Du vertraust.

Hallo Konrad. Ich installiere auf einem BeagleBone Black nun das Linux neu und auch Java. Jedoch kann ich noch immer nicht meine Domain aufrufen. Kannst du mich bitte kurz unterstützen, wie ich das passende Root Zertifikat finde?

Was würdest du an Infos benötigen?

 

[mihe7]

@Fohnbit Geht es um Java als Server oder als Client? Für den Client sollte das Root-Zertifikat reichen. Für einen Server musst Du Dein Zertifikat (plus Intermediate, falls vorhanden) verwenden, wobei dann natürlich auch das betreffende Zertifikat verwendet werden muss. Das root-Zertifikat sollte beim Server nicht notwendig sein; ich meine, dass das überhaupt nicht mitgeschickt wird/werden soll (das root-Zertifikat muss ja beim Client installiert sein, um die Vertrauenswürdigkeit zu prüfen).

 

[KonradN]

Was würdest du an Infos benötigen?

Da ist wirklich wichtig, dass Du uns genau das Szenario mit den Details gibst:

Auf dem BeagleBone läuft dann ein Server? Was für ein Zertifikat hast Du?

Das root Zertifikat solltest Du eigentlich nie manuell hinterlegen müssen. Das ist nur notwendig, wenn Du eine eigene Infrastruktur dafür betreiben willst, wie es große und mittelständische Firmen in der Regel / oft haben.

Du bekommst also eine Zertifikat von einer der vertrauenswürdigen Instanzen (z.B. letsencrypt als kostenlose Variante!). Du brauchst für den Server dann:

• das public Zertifikat
• den private "key"
• das intermediate Zertifikat

Das kannst Du einfach zusammen bauen. Je nach Art der Konfiguration kannst Du das alles in einem Store halten (egal ob java keystore oder pkcs12) oder oft hast Du das auch in separaten Dateien, die Du dann einbindest.

Du musst dann noch etwas auf das Format achten. Es gibt diverse Formate und je nachdem, was genau erwartet wird, musst Du es konvertieren. Das ist dann bei mir immer über openssl Aufrufe.

Das ist aber nur notwendig, wenn Du überhaupt etwas manuell machen musst! Oft hast Du einen Ablauf wie:

• Du hast eine Software, die das Zertifikat braucht. Diese erstellt dann einen Request (und hat dann auch schon den private Key).
• Der Request geht dann an die Stelle, die Zertifikate ausgibt und sendet Dir dann das Zertifikat (ist in erster Linie ein signieren)
• Das, was Du zurück bekommst, bindet die Software dann ein und damit funktioniert schon alles.

letsencrypt
Bei letsencrypt sieht es ähnlich aus - Du hast da ein Tool, das dann beim Webserver ins public Verzeichnis eine Datei stellt und dann den Request absendet. Die Stelle verifiziert, dass Du du den Server kontrollierst über diese Datei und gibt Dir dann das Zertifikat. Und den Server konfigurierst Du dann einfach so, dass das Zertifikat direkt bei dem Tool gelesen wird.

Server hinter Webserver
Damit hast Du das Zertifikat aber nur beim Web-Server. Du willst aber doch irgend einen Java Server haben. Dabei ist es egal, ob Du einen Tomcat oder so aufsetzt oder ob es sich um eine Spring Boot / Quarkus / was auch immer Anwendung handelt.
Dazu richtest Du dann einfach im Webserver einen Proxy ein. Requests gehen also immer erst an den Apache. Und der Apache gibt den dann weiter. Der tomcat (oder was auch immer) läuft also nur lokal (also auf 127.0.0.1) und nur mit http. Um das SSL kümmert sich der Apache (oder nginx oder was auch immer du nutzt)

Das nimmt einen sehr viel Arbeit ab, zumal es sehr viele Tools gibt, um einen Webserver zu konfigurieren. (Ich nutze da immer sehr gerne virtualmin.)

 

[Fohnbit]

Hallo Konrad!

Wie immer vielen Dank für die Ausführlichen Infos.

Konkret:
Ich habe einen Server bei einem Provider wo ich Daten hochlade. Es ist eine InfluxDB.
Auf diesem Webserver im Internet habe ich mein gekauftes wildcard Zertifikat. Wenn ich unter Linux:

curl https://influxdb.company.com

eingebe, erhalte ich den HTML Code. Aus Linux raus wird das Cert am Webserver akzeptiert, ohne das ich da etwas hinzufügen musste.

Nun habe ich Java frisch installiert und versuche in Java https://influxdb.company.com aufzurufen und erhalte:
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Warum muss ich also bei Java ein Zertifikat manuell hinzufügen? Nach einem Jahr muss ich es erneut machen, was ich vermeiden möchte.
Einen Keystore habe ich in Java noch nicht hinzugefügt.

 

[mihe7]

Ruf mal auf Deinem Linuxrechner

openssl s_client -connect influxdb.company.com:443

auf. Da sollte ganz am Anfang der Ausgabe die Certificate Chain ausgegeben werden. Wie sieht die Ausgabe aus?

Warum muss ich also bei Java ein Zertifikat manuell hinzufügen?

Das müssen wir erstmal herausfinden.

Nach einem Jahr muss ich es erneut machen

Dann machst Du vermutlich etwas falsch: ein Wurzelzertifikat ist in der Regel viele Jahre gültig.

 

[Fohnbit]

Ruf mal auf Deinem Linuxrechner

openssl s_client -connect influxdb.company.com:443

auf. Da sollte ganz am Anfang der Ausgabe die Certificate Chain ausgegeben werden. Wie sieht die Ausgabe aus?

DELETED

Das müssen wir erstmal herausfinden.

Vielen Dank.

Dann machst Du vermutlich etwas falsch: ein Wurzelzertifikat ist in der Regel viele Jahre gültig.

Ja, defintiv. Ich muss immer das ganze cert in den keystore speichern.
Wie greift aber Java auf Wurzelzertifikate zu? Scheinbar nicht über das OS, denn da klappt es ja

 

[Fohnbit]

habe etwas nachgeforscht:
Der default keystore liegt in:
$JAVA_HOME/jre/lib/security/cacerts

Diesen habe beim starten des OSGi hinuzgefügt:
-Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacerts


-Djavax.net.ssl.trustStore war bis dato immer ein eigenes File wo ich mein eigenes cert jedes Jahr aktualisieren musste.

Edit:
Ich habe nirgends etwas gefunden, um im Java Code den keystore zu prüfen. Ob er auch wirklich dann diesen nimmt.

 

[LimDul]

OSGi - nun wird ein Schuh draus. Das Problem ist, dass OSGI nicht unbedingt den Keystore des Systems nimmt, sondern einen eigenen. Ich kenne das Problem, dass sich eclipse geweigert hat über SSL zu kommunizieren z.B. mit dem Marketplace, weil es das SSL Zertifikat des Zwangs-Proxy nicht vertraut hat - obwohl das im System hinterlegt war. Da musste man auch an die eclipse.ini rein. Details weiß ich nicht mehr ist schon ca. 3 Jahre her das Problem.

Aber das ist vermutlich wirklich ein OSGI Spezifikum

 

[LimDul]

Nachtrag:

In case you have the certificate already in your Windows' certificate store (this is common in corporate/company deployments with MITM certificates), you can also use the following steps (with help from another Stackoverflow answer with more detailed explaination):

Locate the eclipse.ini file in your Eclipse installation and open it

Below the line -vmargs, add the following lines, then save the file:

-Djavax.net.ssl.trustStore=NUL
-Djavax.net.ssl.trustStoreType=Windows-ROOT
Restart eclipse.

Importing SSL Certificate into Eclipse

How do you import an SSL certificate created by java into a project in Eclipse?

stackoverflow.com

Ist jetzt für Eclipse, sollte aber für jede OSGI Anwendung analog gehen.

 

[Fohnbit]

Nachtrag:

Importing SSL Certificate into Eclipse

How do you import an SSL certificate created by java into a project in Eclipse?

stackoverflow.com

Ist jetzt für Eclipse, sollte aber für jede OSGI Anwendung analog gehen.

Danke! Das ist nun für Windows? Bräuchte es für Linux.

Als vmargs habe ich gesetzt:
-Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacerts
-Djavax.net.ssl.trustStorePassword=changeit

 

[LimDul]

Ich weiß nicht ob Linux auch einen zentralen Keystore hat. Da greift halt das von einer meiner allerersten Aussagen - wenn immer noch Java 8, Update 161 installiert ist, ist es da nicht unerwartet, das da das Root Zertifikat im JRE Keystore fehlt - die Version ist 5 1/2 Jahre alt.
Mit den VM-Args + aktuelle Java Version sollte es gehen.

 

[Fohnbit]

Hab OpenJDK probiert und hat nicht funktioniert. OSGi hat nicht gestartet. Dann die Info vom Softwarelieferanten des OSGi bekommen, das es Java 8 sein muss.
Aktuell habe ich drauf:

java version "1.8.0_381"
Java(TM) SE Runtime Environment (build 1.8.0_381-b09)
Java HotSpot(TM) Client VM (build 25.381-b09, mixed mode)

 

[LimDul]

Das sollte aktuell genug sein, wenn es dann nicht geht, bin ich jetzt auch überfragt. Man könnte mal schauen, was in dem certstore den du oben angegeben hast, drin ist und ob da das root zertifikat drin ist.

 

[mihe7]

---
Certificate chain
 0 s:C = AT, ST = Bundesland, L = beiMir, O = Company GmbH, CN = *.Company.com
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
 1 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
---

D. h. es sollte genügen, wenn das Zertifikat der "Starfield Root Certificate Authority - G2" sich im Keystore für die Wurzelzertifikate (cacerts) befindet.

Das sollte https://ssl-tools.net/subjects/14c0f884650ebfb1564d3da153a0d7f1c7c670a8 sein. Unten kann man sich eine JSON-Ausgabe des self-signed Zertifikats ansehen, dort sieht man die verschiedenen Fingerprints:

sha1: "b51c067cee2b0c3df855ab2d92f4fe39d4e70f0e"
sha256: "2ce1cb0bf9d2f9e102993fbe215152c3b2dd0cabde1c68e5319b839154dbb7f5"
sha512: "5fada52ff721f4f7f14f5a70500531fa7b131d1203eabb29b5c85a39d67cf358287d9d5b9104c8517b9757dba58df9527d07dc9a82f704b8961f8473cdd92ae7"

(Alternativ: Website via Browser aufrufen und sich die Zertifikate anzeigen lassen)

Wenn

keytool -list -cacerts | grep -i "2C:E1"
# bzw
keytool -list -cacerts | grep -i "B5:1C"

einen Fingerprint liefert, der mit einem der oben angegebenen übereinstimmt, ist das Zertifikat bereits im default-"truststore" (cacerts) enthalten. Ich verwende ein JDK 17, ggf. ist der Aufruf von keytool unter Java 8 etwas anders (statt -cacerts könnte z. B. -keystore /pfad/zu/cacerts erforderlich sein)

Zur Sicherheit auch mal eine Website via Java abrufen. Wenn das funktioniert, ist es "einfach" eine Konfigurationssache der OSGI-Anwendung, d. h. Du müsstest herausfinden, welchen truststore die Anwendung verwendet und in diesen das Zertifikat importieren.

 

[Fohnbit]

Wenn

keytool -list -cacerts | grep -i "2C:E1"
# bzw
keytool -list -cacerts | grep -i "B5:1C"

Hallo mihe!

Der erste Befehl liefert eine Ausgabe und ist korrekt.
Der zweite jedocj nicht.

Müssen beide Befehle einen Treffer haben oder nur einer der beiden?

 

[mihe7]

Müssen beide Befehle einen Treffer haben oder nur einer der beiden?

Einer reicht.