Von Code Sentinel, Technical Project Manager & Security-Experte bei Java Fleet Systems Consulting
Schwierigkeit: 🟡 Mittel Lesezeit: 18 Minuten Voraussetzungen: Java-Grundlagen, eine laufende Spring-Boot-Anwendung. Keytool-Erfahrung? Brauchst du nicht – kriegen wir zusammen hin.
⚡ Das Wichtigste in 30 Sekunden
Dein Problem: Deine Spring-Boot-App läuft auf http://localhost:8080 – unverschlüsselt. Für lokale Tests okay, aber spätestens wenn Logins, Tokens oder Kundendaten übertragen werden, brauchst du HTTPS. Und dann stehst du vor Begriffen wie Keystore, PKCS#12, Alias, SAN… und fragst dich, wo du anfangen sollst.
Die Lösung: Mit keytool (steckt schon in deinem JDK!) erstellst du in einer Minute einen Keystore – und mit fünf Zeilen in der application.properties läuft deine App über HTTPS. Bonus: HTTP/2 gibt’s fast geschenkt dazu.
Heute lernst du:
- ✅ Warum der Spring-Security-Starter dich NICHT vor Lauschern schützt (zwei Ebenen!)
- ✅ Was ein Keystore ist und warum PKCS#12 das richtige Format ist (und JKS nicht mehr)
- ✅ Wie du mit
keytoolSchlüsselpaare erstellst – und wann mkcert oder openssl die bessere Wahl sind - ✅ Wie du Spring Boot mit fünf Properties auf HTTPS + HTTP/2 umstellst
- ✅ Bonus: SSL Bundles mit Hot-Reload – der moderne Weg ab Spring Boot 3.1
Für wen ist dieser Artikel?
- 🌱 Anfänger: Du lernst Keystores und HTTPS von Grund auf
- 🌿 Erfahrene: Du bekommst die saubere Spring-Boot-Konfiguration inkl. Stolperfallen (SAN!)
- 🌳 Profis: Im Bonus warten SSL Bundles, Zertifikats-Hot-Reload und die Reverse-Proxy-Frage
Zeit-Investment: 18 Minuten Lesen, 10 Minuten Umsetzen
👋 Code Sentinel: „Dein Passwort reist gerade im Klartext durchs Netz“
Hey! Code Sentinel hier. Schön, dass du wieder da bist! 😊
Real talk: Ich habe früher jede HTTP-Verbindung wie einen offenen Brandherd behandelt. Heute sehe ich das entspannter – aber bei einem Punkt bleibe ich hart: Sobald Credentials oder personenbezogene Daten über die Leitung gehen, ist HTTP keine Option mehr. Nicht „sollte man mal machen“. Keine Option.
Kennst du das? Du willst „nur schnell“ HTTPS aktivieren, googelst dich durch fünf Tutorials, und jedes zweite zeigt dir veraltete JKS-Befehle aus 2015, bei denen dein Browser das Zertifikat am Ende trotzdem ablehnt. Frustrierend.
Ich zeige dir heute den Weg, der 2026 funktioniert – pragmatisch, mit den drei wichtigsten Handgriffen statt fünfzehn theoretischen. Das Beste: Alles, was du brauchst, liegt schon auf deinem Rechner.
Lass uns das gemeinsam angehen! 🚀
🖼️ Das Konzept auf einen Blick
Abbildung 1: keytool verwaltet den Keystore – Spring Boot nutzt ihn für HTTPS.
🟢 GRUNDLAGEN
Was ist HTTPS – und warum brauche ich das?
HTTPS ist HTTP über eine verschlüsselte TLS-Verbindung. Ohne HTTPS kann jeder, der zwischen Browser und Server sitzt (öffentliches WLAN, kompromittierter Router, neugieriger Netzbetreiber), mitlesen und sogar Inhalte verändern. Mit HTTPS bekommst du drei Dinge:
- Vertraulichkeit – niemand liest mit
- Integrität – niemand manipuliert unterwegs die Daten
- Authentizität – der Browser weiß, dass er wirklich mit deinem Server spricht
Damit dein Server das leisten kann, braucht er zwei Dinge: einen privaten Schlüssel und ein Zertifikat. Und genau die wohnen in einem Keystore.
„Moment – ich nutze doch Spring Security, dann bin ich doch sicher?“
Diesen Satz höre ich in fast jedem Projekt-Kickoff, deshalb klären wir das direkt am Anfang: Nein. Und das ist kein Detail, sondern der gefährlichste Irrglaube in diesem ganzen Themenfeld.
Spring Security und HTTPS lösen zwei völlig verschiedene Probleme auf zwei verschiedenen Ebenen:
| HTTPS / TLS | Spring Security | |
|---|---|---|
| Ebene | Transport (die Leitung) | Anwendung (deine App) |
| Frage | „Kann jemand mitlesen oder manipulieren?“ | „Wer bist du und was darfst du?“ |
| Schützt gegen | Lauscher im Netzwerk, Man-in-the-Middle, gefälschte Server | Unbefugten Zugriff, CSRF, Session-Klau in der App |
| Weiß nichts über | User, Logins, Rollen | Die Verschlüsselung der Verbindung |
Das heißt konkret: Du kannst die perfekteste Spring-Security-Konfiguration der Welt haben – Login-Formular, BCrypt-gehashte Passwörter, Rollen, CSRF-Schutz, alles vorbildlich. Wenn die App über HTTP läuft, wandert das Passwort deiner Nutzer trotzdem im Klartext durchs Netz. Der Angreifer im Café-WLAN braucht deine Security-Filter-Chain gar nicht zu knacken – er liest einfach den Login-Request mit, bevor er bei deiner App ankommt.
Abbildung 2: Zwei Schutzschichten, zwei Ebenen – die eine ersetzt die andere nicht.
Die Merkregel für dein nächstes Team-Meeting:
Spring Security entscheidet, WER rein darf. HTTPS sorgt dafür, dass unterwegs NIEMAND mitliest. Du brauchst beides.
Umgekehrt gilt es übrigens genauso: HTTPS allein macht deine App nicht sicher. Eine verschlüsselte Verbindung zu einem Endpoint, den jeder ohne Login aufrufen darf, ist… eine sehr vertrauliche Unterhaltung mit einem Einbrecher. In diesem Artikel kümmern wir uns um die Transport-Ebene – die Anwendungs-Ebene (Spring Security) verdient ihren eigenen Deep-Dive.
💡 Neu hier? Was ist ein Zertifikat?
Ein Zertifikat ist wie ein digitaler Ausweis für deinen Server. Es enthält den öffentlichen Schlüssel und Angaben darüber, wem der Server gehört. Browser prüfen diesen Ausweis, bevor sie Daten senden.
Beispiel: Wenn du
https://java-developer.onlineaufrufst, zeigt dir das Schloss-Symbol im Browser, dass das Zertifikat geprüft wurde.
Was ist ein Keystore? Und was ist keytool?
Ein Keystore ist eine passwortgeschützte Datei – ein Tresor für Schlüssel und Zertifikate. Jeder Eintrag im Tresor hat einen Alias (einen Namen), damit du mehrere Schlüssel in einer Datei verwalten kannst.
Das Werkzeug dafür heißt keytool und liegt in jedem JDK im bin-Verzeichnis. Kein Download, keine Installation – wenn du Java hast, hast du keytool. Damit kannst du Keystores erstellen, lesen und ändern.
PKCS#12 oder JKS – welches Format?
Es gibt zwei Keystore-Formate, die dir begegnen werden:
PKCS#12 (Dateiendung .p12 oder .pfx) steht für Public Key Cryptography Standards, Nummer 12. Es ist ein offener Industriestandard – die Details stehen in RFC 7292. Seit Java 9 ist PKCS#12 das Standardformat, und es funktioniert auch außerhalb der Java-Welt (OpenSSL, Windows, Webserver).
JKS (Java KeyStore, Endung .jks) ist das alte, Java-proprietäre Format. Es funktioniert noch, aber: keytool warnt dich inzwischen aktiv, wenn du es benutzt, und empfiehlt die Migration zu PKCS#12. Die Krypto-Standards von JKS gelten als schwächer.
Meine klare Empfehlung: Neue Projekte → immer PKCS#12. JKS nur noch anfassen, wenn du ein Bestandssystem pflegst.
Abbildung 3: PKCS#12 vs. JKS – für neue Projekte gibt es nur eine richtige Wahl.
Dein erster Blick in einen echten Keystore: cacerts
Bevor wir selbst etwas erstellen, schauen wir uns einen Keystore an, den du schon besitzt: In deinem JDK liegt die Datei cacerts – der Truststore mit allen Zertifizierungsstellen, denen Java vertraut. So listest du den Inhalt auf:
# Seit Java 9 gibt es die bequeme Abkürzung -cacerts: keytool -list -cacerts # Standard-Passwort: changeit
Auf meinem Rechner (JDK 21, Amazon Corretto) liefert das rund 150 Einträge – jede Zeile ein Zertifikat einer Zertifizierungsstelle. Genau so kannst du später auch in deine Keystores hineinschauen:
keytool -list -keystore beispiel.p12
Dein erstes Schlüsselpaar erstellen
Jetzt wird’s praktisch. Mit keytool -genkeypair erstellst du ein Schlüsselpaar (privater + öffentlicher Schlüssel) samt selbstsigniertem Zertifikat. Hier der komplette Befehl zum Kopieren – eine Zeile, ich erkläre danach jeden Parameter:
keytool -genkeypair -alias beispiel -keyalg RSA -keysize 4096 -sigalg SHA256withRSA -dname "cn=localhost,ou=beispiel,o=beispiel,c=DE" -ext "san=dns:localhost,ip:127.0.0.1" -validity 365 -storetype PKCS12 -storepass changeit -keystore beispiel.p12
Was die Parameter bedeuten:
| Parameter | Bedeutung |
|---|---|
-alias beispiel | Name des Eintrags im Keystore. Darüber findest du den Schlüssel später wieder. |
-keyalg RSA | Algorithmus für das Schlüsselpaar, z. B. RSA oder EC. |
-keysize 4096 | Schlüssellänge in Bit. 4096 ist konservativ-sicher, 3072 wäre das Minimum für RSA. |
-sigalg SHA256withRSA | Signaturalgorithmus für das Zertifikat. SHA256withRSA ist der übliche Standard. |
-dname "cn=..." | Distinguished Name: Wer steckt hinter dem Zertifikat? CN = Common Name (Hostname!), OU = Abteilung, O = Organisation, C = Land. |
-ext "san=..." | Subject Alternative Name – der wichtigste Parameter! Moderne Browser ignorieren den CN und prüfen nur noch die SAN-Einträge. Ohne SAN lehnt Chrome dein Zertifikat ab. Details gleich in den Stolperfallen. |
-validity 365 | Gültigkeit in Tagen ab heute. Hier: ein Jahr. |
-storetype PKCS12 | Format des Keystores. Seit Java 9 ohnehin Default – ich schreibe es trotzdem explizit hin. Explizit schlägt implizit. |
-storepass changeit | Passwort für die Keystore-Datei. Bei PKCS#12 gilt es automatisch auch für den Schlüssel. |
-keystore beispiel.p12 | Pfad und Name der Keystore-Datei, die erstellt wird. |
💡 Neu hier? Was heißt „selbstsigniert“?
Normalerweise bestätigt eine Zertifizierungsstelle (CA) die Echtheit eines Zertifikats. Ein selbstsigniertes Zertifikat hat sich sozusagen selbst den Ausweis ausgestellt. Für lokale Entwicklung völlig okay – Browser zeigen aber eine Warnung, weil ihnen die „Selbstauskunft“ nicht reicht. Für Produktion brauchst du ein echtes Zertifikat (dazu mehr im Bonus).
Kleines Experiment: Führ den Befehl ein zweites Mal aus, aber mit -alias beispiel2. Dann lass dir den Inhalt anzeigen:
keytool -list -keystore beispiel.p12
Du siehst jetzt zwei Einträge – ein Keystore kann beliebig viele Schlüsselpaare enthalten, unterschieden per Alias. Das war’s! Dein erster eigener Keystore! 🎉
💡 Du kennst die Basics schon? → Spring direkt zu PROFESSIONALS
🟡 PROFESSIONALS
Spring Boot auf HTTPS umstellen
Mit dem Wissen von oben ist die Spring-Boot-Konfiguration fast schon langweilig einfach. Kopiere beispiel.p12 nach src/main/resources und trage in die application.properties ein:
# HTTPS aktivieren server.port=8443 server.ssl.key-store-type=PKCS12 server.ssl.key-store=classpath:beispiel.p12 server.ssl.key-store-password=changeit server.ssl.key-alias=beispiel # HTTP/2 einschalten server.http2.enabled=true
Die Werte kommen 1:1 aus unserem keytool -genkeypair-Befehl: dasselbe Passwort, derselbe Alias, dieselbe .p12-Datei. Der Keystore-Typ ist PKCS12. JKS-Keystores funktionieren mit server.ssl.key-store-type=JKS übrigens genauso – aber du weißt ja jetzt, warum du das nicht mehr willst. 😉
Die letzte Property aktiviert HTTP/2. Wichtig zu wissen: Browser sprechen HTTP/2 ausschließlich über TLS. Ist HTTPS nicht konfiguriert, wird die Property schlicht ignoriert.
App starten, https://localhost:8443 aufrufen – fertig. Die Browser-Warnung wegen des selbstsignierten Zertifikats ist erwartbar (siehe Stolperfallen), einmal bestätigen und weiter.
Abbildung 4: Was beim Aufruf von https://localhost:8443 wirklich passiert.
Verifizieren wie ein Profi
Trau keiner Konfiguration, die du nicht getestet hast. Zwei schnelle Checks:
# Check 1: Antwortet der Server über TLS? (-k akzeptiert selbstsignierte Zertifikate) curl -kv https://localhost:8443 # Check 2: Läuft wirklich HTTP/2? curl -k --http2 -I https://localhost:8443 # In der Antwort solltest du "HTTP/2 200" sehen
Stolperfallen vermeiden
Stolperfalle 1: Das SAN-Problem (der Klassiker!) Viele ältere Tutorials erstellen Zertifikate ohne -ext san=.... Ergebnis: Chrome, Edge und Firefox lehnen das Zertifikat mit NET::ERR_CERT_COMMON_NAME_INVALID ab, obwohl der CN korrekt ist. Der Grund: Browser prüfen seit Jahren nur noch den Subject Alternative Name, nicht mehr den Common Name. Deshalb steht der SAN-Parameter bei uns von Anfang an im Befehl.
Stolperfalle 2: Passwörter im Klartext in der application.properties Für lokale Entwicklung okay. Aber committe niemals einen produktiven Keystore samt Passwort ins Git-Repository. Nutze stattdessen Umgebungsvariablen:
server.ssl.key-store-password=${SSL_KEYSTORE_PASSWORD}
Real talk: Ich habe schon Audits gesehen, bei denen produktive Keystore-Passwörter seit Jahren in der Git-History lagen. Das Aufräumen danach kostet mehr Nerven als die Umgebungsvariable von Anfang an.
Stolperfalle 3: classpath: vs. Dateipfad classpath:beispiel.p12 funktioniert nur, wenn die Datei im JAR steckt (src/main/resources). In Produktion willst du den Keystore meist außerhalb des JARs austauschen können:
server.ssl.key-store=file:/etc/myapp/beispiel.p12
Stolperfalle 4: Abgelaufene Zertifikate -validity 365 heißt: In einem Jahr ist Schluss – und zwar kommentarlos. Prüfe das Ablaufdatum mit keytool -list -v -keystore beispiel.p12 und trag dir eine Erinnerung ein. Oder besser: Lies den Bonus-Teil zum Hot-Reload.
Stolperfalle 5: Alter JKS-Keystore im Projekt Du übernimmst ein Legacy-Projekt mit .jks-Datei? Die Migration ist ein Einzeiler:
keytool -importkeystore -srckeystore alt.jks -destkeystore neu.p12 -deststoretype PKCS12
Alternativen zu keytool: openssl, mkcert & KeyStore Explorer
keytool ist praktisch, weil es überall dabei ist – aber es ist nicht das einzige Werkzeug. Drei Alternativen solltest du kennen, jede mit einem klaren Einsatzzweck:
mkcert – die beste Wahl für lokale Entwicklung
mkcert löst genau das Problem, das dich bei selbstsignierten keytool-Zertifikaten am meisten nervt: die Browser-Warnung. Es erstellt eine lokale Mini-CA, trägt sie einmalig in den Truststore deines Systems ein – und ab dann sind alle mkcert-Zertifikate in deinen Browsern grün. Kein Wegklicken mehr, kein rotes Schloss:
# Einmalig: lokale CA installieren mkcert -install # Zertifikat für localhost erstellen – direkt als PKCS#12 für Spring Boot! mkcert -pkcs12 -p12-file beispiel.p12 localhost 127.0.0.1 # Standard-Passwort der erzeugten Datei: changeit
Zwei Befehle, und deine Spring-Boot-App läuft lokal mit grünem Schloss. Die SAN-Einträge setzt mkcert automatisch korrekt. Wichtig zur Einordnung: Das ist ein reines Entwicklungs-Werkzeug – die mkcert-CA gehört niemals auf Produktions- oder fremde Rechner.
openssl – der Standard außerhalb der Java-Welt
OpenSSL ist das Schweizer Taschenmesser der TLS-Welt. Wenn du mit nginx, certbot oder Ops-Kollegen arbeitest, bekommst du Schlüssel und Zertifikate meist als PEM-Dateien (.key / .crt) – und openssl ist die Brücke in deinen Keystore:
# Selbstsigniertes Zertifikat inkl. SAN erstellen (eine Zeile, keine Interaktion) openssl req -x509 -newkey rsa:4096 -sha256 -days 365 -nodes \ -keyout beispiel.key -out beispiel.crt \ -subj "/CN=localhost" \ -addext "subjectAltName=DNS:localhost,IP:127.0.0.1" # PEM-Dateien in einen PKCS#12-Keystore für Spring Boot packen openssl pkcs12 -export -in beispiel.crt -inkey beispiel.key \ -name beispiel -out beispiel.p12 -passout pass:changeit
Genau dieser zweite Befehl ist auch der Weg, wenn dir jemand ein „echtes“ Zertifikat als PEM liefert und du es in Spring Boot einbinden willst. (Kleiner Reminder aus dem Bonus: Spring Boot 3.1+ kann PEM auch direkt lesen – dann sparst du dir den Umweg komplett.)
KeyStore Explorer – wenn du es lieber visuell magst
Der KeyStore Explorer ist eine Open-Source-GUI für Keystores: Einträge ansehen, umbenennen, importieren, Formate konvertieren, Ablaufdaten auf einen Blick prüfen – alles per Klick statt Kommandozeile. Gerade beim Debuggen fremder Keystores („Was ist da eigentlich drin und wann läuft es ab?“) schneller als jede -list -v-Ausgabe.
Meine Einordnung: mkcert für den lokalen Alltag, openssl für alles an der Schnittstelle zu Ops und Produktion, KeyStore Explorer zum Inspizieren – und keytool bleibt dein Werkzeug, wenn nichts installiert werden darf oder du auf einem fremden Server nur das JDK hast. Das Konzept dahinter (Keystore, Alias, SAN) ist bei allen identisch – deshalb haben wir es zuerst gelernt.
💡 Du willst mehr? → Im BONUS findest du SSL Bundles, Hot-Reload und die Produktions-Perspektive
🔵 BONUS
SSL Bundles: Der moderne Weg (Spring Boot 3.1+)
Die klassischen server.ssl.*-Properties funktionieren – aber seit Spring Boot 3.1 gibt es SSL Bundles: Du definierst TLS-Material einmal zentral und referenzierst es überall (Webserver, RestClient, Datenbank-Verbindungen):
# Bundle definieren
spring.ssl.bundle.jks.server.keystore.location=file:/etc/myapp/beispiel.p12
spring.ssl.bundle.jks.server.keystore.password=${SSL_KEYSTORE_PASSWORD}
spring.ssl.bundle.jks.server.keystore.type=PKCS12
spring.ssl.bundle.jks.server.key.alias=beispiel
# Bundle dem Webserver zuweisen
server.ssl.bundle=server
server.http2.enabled=true
(Ja, der Property-Namespace heißt jks – auch für PKCS#12-Dateien. Historisch gewachsen, ich habe auch die Augen verdreht.)
Zertifikats-Hot-Reload: Kein Neustart mehr
Der eigentliche Killer-Vorteil von Bundles: Reload ohne Neustart. Eine Property dazu:
spring.ssl.bundle.jks.server.reload-on-update=true
Spring Boot überwacht die Keystore-Datei und lädt das Zertifikat bei Änderung neu. In Kombination mit automatischer Zertifikats-Erneuerung (z. B. Let’s Encrypt, alle 90 Tage) heißt das: kein geplanter Neustart, keine Downtime, kein „Zertifikat abgelaufen“-Incident am Sonntagmorgen. Das ist Security, die Speed ermöglicht statt verhindert.
Selbstsigniert vs. echtes Zertifikat: Die Produktions-Frage
Selbstsignierte Zertifikate sind für lokale Entwicklung und interne Tests gedacht – Punkt. Für alles, was Nutzer erreicht, brauchst du ein Zertifikat einer echten CA. Let’s Encrypt stellt sie kostenlos und automatisiert aus.
Und hier die Architektur-Entscheidung, die du bewusst treffen solltest:
Option A – TLS-Terminierung am Reverse Proxy: nginx oder Traefik übernimmt HTTPS samt Zertifikatsverwaltung, Spring Boot läuft dahinter über HTTP im internen Netz. Vorteil: Zertifikats-Handling zentral, bewährte Tools (certbot). Das ist das häufigste Produktions-Setup. Wichtig: Dann brauchst du server.forward-headers-strategy=framework, damit Spring die ursprünglichen Client-Infos kennt.
Option B – End-to-End-TLS bis in die App: Spring Boot terminiert TLS selbst, wie in diesem Artikel gezeigt. Vorteil: Verschlüsselung bis zum letzten Meter – in Zero-Trust-Umgebungen oder bei strengen Compliance-Vorgaben Pflicht.
Meine pragmatische Einordnung: Für die meisten Mittelstands-Setups ist Option A völlig ausreichend. Option B, wenn dein internes Netz nicht als vertrauenswürdig gilt. Beide sind valide – „kommt drauf an“ ist hier keine Ausrede, sondern die ehrliche Antwort.
HTTP/2 im Detail: h2 vs. h2c
HTTP/2 über TLS heißt h2, die unverschlüsselte Variante h2c. Browser unterstützen ausschließlich h2 – die Protokoll-Aushandlung passiert per ALPN direkt im TLS-Handshake (siehe Abbildung 4). Deshalb ist server.http2.enabled=true ohne HTTPS im Browser-Kontext wirkungslos. Der Gewinn von HTTP/2: Multiplexing (viele Requests über eine Verbindung), Header-Kompression, keine Head-of-Line-Blockade auf HTTP-Ebene. Gerade bei asset-lastigen Frontends messbar schneller.
RSA oder EC?
Unser Beispiel nutzt RSA 4096 – robust, überall unterstützt, aber rechenintensiv. Die moderne Alternative sind elliptische Kurven:
keytool -genkeypair -alias beispiel-ec -keyalg EC -groupname secp256r1 -sigalg SHA256withECDSA ...
EC-Schlüssel sind bei gleicher Sicherheit deutlich kleiner und machen den TLS-Handshake schneller. Für neue Setups eine Überlegung wert – solange keine Legacy-Clients RSA erzwingen.
💡 Praxis-Tipps
Für Einsteiger 🌱
- Tipp den keytool-Befehl einmal komplett selbst ab statt nur zu kopieren – so lernst du, was jeder Parameter tut. Danach darfst du für immer kopieren, versprochen.
- Die Browser-Warnung bei selbstsignierten Zertifikaten ist normal. Sie heißt nicht „kaputt“, sondern „keine CA hat das bestätigt“. Lokal: einmal bestätigen, weiterarbeiten.
Für den Alltag 🌿
- Keystore raus aus dem JAR, Passwort raus aus dem Code.
file:-Pfad plus Umgebungsvariable ist der Minimal-Standard für alles jenseits von localhost. keytool -list -vgehört in deine Deployment-Checkliste. Ablaufdatum, SAN-Einträge, Alias – 30 Sekunden Kontrolle ersparen dir den 2-Stunden-Incident.
Für Profis 🌳
- Migriere auf SSL Bundles mit
reload-on-update=true. Zertifikatswechsel ohne Neustart ist der Unterschied zwischen „Wartungsfenster planen“ und „passiert einfach“. - Teste deine TLS-Konfiguration extern – mit dem SSL Labs Server Test für öffentliche Endpoints. Alles unter Note A ist ein Arbeitsauftrag.
🛠️ Tools & Ressourcen
Für Einsteiger 🌱
| Tool | Warum? | Link |
|---|---|---|
| keytool (im JDK) | Schon installiert – Keystores erstellen und verwalten | Dokumentation |
| mkcert | Lokale Zertifikate ohne Browser-Warnung – zwei Befehle, grünes Schloss | GitHub |
| Spring Initializr | Frisches Spring-Boot-Projekt zum Ausprobieren | start.spring.io |
Für den Alltag 🌿
| Tool | Warum? | Link |
|---|---|---|
| curl | HTTPS und HTTP/2 von der Kommandozeile testen | curl.se |
| openssl | PEM-Zertifikate erstellen und in PKCS#12 konvertieren – die Brücke zur Ops-Welt | openssl.org |
| KeyStore Explorer | Keystores per GUI inspizieren, konvertieren, debuggen | keystore-explorer.org |
| Let’s Encrypt / certbot | Kostenlose, automatisierte Zertifikate für Produktion | letsencrypt.org |
Für Profis 🌳
| Tool | Warum? | Link |
|---|---|---|
| SSL Labs Server Test | TLS-Konfiguration extern bewerten lassen | ssllabs.com/ssltest |
| Mozilla SSL Config Generator | Empfohlene TLS-Einstellungen für Proxys generieren | ssl-config.mozilla.org |
❓ FAQ (Häufige Fragen)
Frage 1: Muss ich für lokale Entwicklung überhaupt HTTPS einrichten?
Antwort: Nicht immer – aber sobald du Features testest, die HTTPS voraussetzen (Secure Cookies, Service Worker, HTTP/2, manche OAuth-Flows), kommst du nicht drumherum. Und ehrlich: Wenn das Setup nur zehn Minuten dauert, gibt es wenig Gründe dagegen.
Frage 2: Ich bekomme „keytool: command not found“ – was nun?
Antwort: keytool liegt im bin-Verzeichnis deines JDK. Entweder ist das JDK nicht installiert oder das bin-Verzeichnis fehlt in deiner PATH-Variable. Prüfe mit java -version, ob Java gefunden wird – wenn ja, liegt keytool im selben Verzeichnis wie das java-Binary.
Frage 3: Warum meckert mein Browser trotz korrektem Zertifikat?
Antwort: In neun von zehn Fällen: fehlender oder falscher SAN-Eintrag. Prüfe mit keytool -list -v -keystore beispiel.p12, ob unter SubjectAlternativeName wirklich dns:localhost steht. Der zehnte Fall: Das Zertifikat ist abgelaufen.
Frage 4: Kann ich HTTP und HTTPS parallel anbieten?
Antwort: Spring Boot unterstützt out of the box nur einen Connector. Du kannst programmatisch einen zweiten Tomcat-Connector auf Port 8080 registrieren, der auf 8443 weiterleitet – das ist das übliche Pattern für „HTTP nur als Redirect“. In Produktion übernimmt diese Weiterleitung meist der Reverse Proxy.
Frage 5: Was ist der Unterschied zwischen -storepass und -keypass?
Antwort: -storepass schützt die Keystore-Datei als Ganzes, -keypass einen einzelnen privaten Schlüssel darin. Bei PKCS#12 sind beide technisch identisch – ein separates -keypass wird ignoriert bzw. muss gleich sein. Das ist einer der Gründe, warum PKCS#12 einfacher zu handhaben ist als JKS.
Frage 6: JKS, PKCS#12, PEM – wann brauche ich was?
Antwort: PKCS#12 für alles Neue in der Java-Welt. JKS nur für Bestandssysteme. PEM (.crt/.key-Dateien) begegnet dir bei nginx, certbot und OpenSSL – Spring Boot 3.1+ kann PEM übrigens auch direkt lesen (spring.ssl.bundle.pem.*), ganz ohne Keystore-Umweg.
Frage 7: Stimmt es, dass Bernd seinen Keystore seit 2009 nicht angefasst hat? 🤔
Antwort: Kein Kommentar zu laufenden Sicherheitsvorgängen. 😄 Aber ja – bei der letzten Bestandsaufnahme fanden wir einen JKS-Keystore, erstellt 2009, Passwort… sagen wir: kreativ schwach. Bernds Verteidigung: „Der läuft seit 17 Jahren stabil, DAS nenne ich Zuverlässigkeit.“ Wir haben migriert. Bernd hat drei Tage lang demonstrativ geseufzt. Wer wissen will, was bei uns intern sonst noch so passiert: Es gibt Gerüchte über versteckte Logbücher auf diesem Blog… 👀
Frage 8: Wie erneuere ich ein ablaufendes Zertifikat ohne Downtime?
Antwort: Mit SSL Bundles und reload-on-update=true (siehe Bonus): neue .p12-Datei an denselben Pfad legen, Spring Boot lädt sie automatisch nach. Ohne Bundles bleibt nur der Neustart – plane ihn, bevor das alte Zertifikat abläuft, nicht danach.
Frage 9: Ich habe den Spring-Security-Starter in der pom.xml – reicht das nicht?
Antwort: Nein, und diese Frage kommt so oft, dass sie einen eigenen Abschnitt bekommen hat (→ hier). Kurzfassung: Spring Security regelt Authentifizierung und Autorisierung in deiner App. Die Verbindung zu deiner App verschlüsselt es nicht. Login-Formular über HTTP = Passwort im Klartext im Netz, egal wie gut deine Security-Konfiguration ist. Beide Ebenen, immer.
Frage 10: keytool, openssl oder mkcert – was soll ich denn jetzt nehmen?
Antwort: Lokale Entwicklung mit Browser: mkcert (kein Warnhinweis, korrekte SANs automatisch). Zertifikate von Ops/CA als PEM bekommen: openssl zum Konvertieren – oder gleich PEM-Support der SSL Bundles nutzen. Auf einem fremden Server, wo nur das JDK liegt: keytool. Das zugrundeliegende Konzept ist bei allen dasselbe.
💬 Real Talk: Die rote Browser-Warnung
Java Fleet Küche, 12:40 Uhr. Nova balanciert ihren Laptop neben eine dampfende Nudelbox. Tom rührt in seinem Joghurt, Code Sentinel wartet auf den Espresso – und summt dabei leise vor sich hin.
Nova: „Code, kurze Panik-Frage: Ich hab HTTPS nach Anleitung eingerichtet und Chrome schreit mich mit einer roten Warnseite an. ‚Dies ist keine sichere Verbindung.‘ Hab ich’s kaputt gemacht?“
Code Sentinel: „Chill, nichts ist kaputt. Was steht als Fehlercode unten auf der Seite?“
Nova: „Ähm… ERR_CERT_AUTHORITY_INVALID.“
Code Sentinel: „Alles gut – das ist die erwartbare Warnung. Dein Zertifikat ist selbstsigniert. Chrome sagt nur: ‚Ich kenne niemanden, der für diesen Server bürgt.‘ Für localhost völlig okay, einmal auf ‚Erweitert‘ und ‚Trotzdem fortfahren‘ klicken.“
Tom: „Moment – wofür machen wir dann überhaupt Zertifizierungsstellen, wenn man die Warnung eh wegklicken kann?“
Code Sentinel: „Gute Frage. Lokal weißt du, dass der Server dir gehört – da ist Wegklicken rational. Im Internet weißt du das nicht. Da bürgt die CA dafür, dass hinter java-developer.online wirklich wir stecken und kein Angreifer. Deshalb: lokal selbstsigniert okay, produktiv niemals.“
Nova: „Ohhh. Also ist die Warnung gar kein Fehler, sondern Chrome macht genau seinen Job.“
Code Sentinel: „Exakt. Und merk dir für später: Wenn die Meldung COMMON_NAME_INVALID heißt statt AUTHORITY_INVALID, dann fehlt dein SAN-Eintrag – das ist dann tatsächlich ein Fehler im Zertifikat. Die zwei auseinanderhalten zu können spart dir irgendwann einen halben Nachmittag.“
Tom: „Kommt das in die Klausur?“ grinst
Code Sentinel: „Das kommt ins Leben, das ist schlimmer.“ schaut auf die Uhr „So, ich muss um 18 Uhr pünktlich raus heute – also lasst uns Novas Setup direkt nach dem Essen kurz durchgehen.“ 😉
Nova klappt den Laptop zu und widmet sich den Nudeln. Krise abgesagt, Mittagspause gerettet.
🎁 Cheat Sheet
🟢 Basics (Zum Nachschlagen)
# Keystore-Inhalt auflisten keytool -list -keystore beispiel.p12 # Java-Truststore anzeigen (Passwort: changeit) keytool -list -cacerts # Details eines Eintrags (Ablaufdatum, SAN!) keytool -list -v -keystore beispiel.p12 -alias beispiel
🟡 Patterns (Für den Alltag)
# Schlüsselpaar + selbstsigniertes Zertifikat (mit SAN!) keytool -genkeypair -alias beispiel -keyalg RSA -keysize 4096 \ -sigalg SHA256withRSA \ -dname "cn=localhost,ou=beispiel,o=beispiel,c=DE" \ -ext "san=dns:localhost,ip:127.0.0.1" \ -validity 365 -storetype PKCS12 \ -storepass changeit -keystore beispiel.p12 # JKS nach PKCS#12 migrieren keytool -importkeystore -srckeystore alt.jks \ -destkeystore neu.p12 -deststoretype PKCS12 # Eintrag löschen keytool -delete -alias beispiel2 -keystore beispiel.p12
# Spring Boot: HTTPS + HTTP/2 (klassisch) server.port=8443 server.ssl.key-store-type=PKCS12 server.ssl.key-store=classpath:beispiel.p12 server.ssl.key-store-password=changeit server.ssl.key-alias=beispiel server.http2.enabled=true
🔵 Advanced (Für Profis)
# SSL Bundle mit Hot-Reload (Spring Boot 3.1+)
spring.ssl.bundle.jks.server.keystore.location=file:/etc/myapp/beispiel.p12
spring.ssl.bundle.jks.server.keystore.password=${SSL_KEYSTORE_PASSWORD}
spring.ssl.bundle.jks.server.keystore.type=PKCS12
spring.ssl.bundle.jks.server.key.alias=beispiel
spring.ssl.bundle.jks.server.reload-on-update=true
server.ssl.bundle=server
server.http2.enabled=true
# HTTP/2 verifizieren curl -k --http2 -I https://localhost:8443 # EC statt RSA (schnellerer Handshake) keytool -genkeypair -alias beispiel-ec -keyalg EC \ -groupname secp256r1 -sigalg SHA256withECDSA \ -dname "cn=localhost" -ext "san=dns:localhost" \ -validity 365 -storetype PKCS12 \ -storepass changeit -keystore beispiel-ec.p12
🎨 Challenge für dich!
Wähle dein Level:
🟢 Level 1 – Einsteiger
- [ ] Erstelle mit keytool einen PKCS#12-Keystore mit zwei Aliassen und lass dir den Inhalt mit
keytool -listanzeigen - [ ] Stelle eine frische Spring-Boot-App (start.spring.io) auf HTTPS um und rufe sie im Browser auf
Geschätzte Zeit: 15-30 Minuten
🟡 Level 2 – Fortgeschritten
- [ ] Verifiziere mit curl, dass deine App wirklich HTTP/2 spricht
- [ ] Lagere den Keystore aus dem JAR aus (
file:-Pfad) und das Passwort in eine Umgebungsvariable - [ ] Erstelle absichtlich ein Zertifikat OHNE SAN und beobachte, welche Fehlermeldung dein Browser zeigt
- [ ] Installiere mkcert, erzeuge damit einen PKCS#12-Keystore und genieße das grüne Schloss ohne Warnung
Geschätzte Zeit: 30-60 Minuten
🔵 Level 3 – Profi
- [ ] Migriere deine Konfiguration auf SSL Bundles mit
reload-on-update=trueund teste den Hot-Reload: Erstelle ein neues Zertifikat, ersetze die Datei im laufenden Betrieb und prüfe im Browser das neue Ablaufdatum – ohne Neustart - [ ] Baue ein Setup mit nginx als TLS-terminierendem Reverse Proxy vor deiner Spring-Boot-App und konfiguriere
server.forward-headers-strategy=framework
Geschätzte Zeit: 1-2 Stunden
Teile dein Ergebnis! 🎉
📦 Downloads
Alle Code-Beispiele zum Herunterladen:
| Projekt | Für wen? | Download |
|---|---|---|
| https-basic.zip | 🟢 Einsteiger – Spring Boot + fertiger Beispiel-Keystore | ⬇️ Download |
| https-complete.zip | 🟡 Alle Levels – inkl. SSL-Bundle-Konfiguration | ⬇️ Download |
| https-advanced.zip | 🔵 Profis – Hot-Reload-Demo + nginx-Beispielkonfiguration | ⬇️ Download |
Quick Start:
# 1. ZIP entpacken unzip https-basic.zip && cd https-basic # 2. Eigenen Keystore erstellen (Windows: create-keystore.bat) ./create-keystore.sh # 3. Starten (Maven + JDK 21 vorausgesetzt) mvn spring-boot:run # → https://localhost:8443/hello
Probleme? → FAQ
🔗 Weiterführende Links
📚 Für Einsteiger
| Ressource | Beschreibung |
|---|---|
| Spring Boot Docs: SSL konfigurieren | Offizielle Anleitung, kompakt und aktuell |
| keytool-Referenz (Oracle, JDK 21) | Alle Parameter im Detail |
| Baeldung: HTTPS mit selbstsigniertem Zertifikat | Schritt-für-Schritt-Tutorial mit Screenshots |
🛠️ Tools & Extensions
| Tool | Beschreibung |
|---|---|
| Let’s Encrypt | Kostenlose Zertifikate für Produktion, automatisierbar |
| SSL Labs Server Test | Externe Bewertung deiner TLS-Konfiguration |
| Mozilla SSL Config Generator | Empfohlene TLS-Settings für nginx, Apache & Co. |
📖 Für Fortgeschrittene
| Ressource | Beschreibung |
|---|---|
| Spring Boot Docs: SSL Bundles | Zentrale TLS-Verwaltung inkl. Hot-Reload |
| RFC 7292 – PKCS#12 | Die Spezifikation hinter dem .p12-Format |
| MDN: HTTP/2 | Hintergrund zu Multiplexing & Protokoll-Evolution |
📧 Offizielle Dokumentation
💬 Geschafft! 🎉
Was du heute gelernt hast:
✅ Spring Security und HTTPS sind zwei verschiedene Ebenen – der Starter allein verschlüsselt gar nichts ✅ Keystores sind Tresore für Schlüssel und Zertifikate – PKCS#12 ist der Standard, JKS ist Geschichte ✅ Mit keytool -genkeypair (inklusive SAN!) erstellst du in einer Minute ein Entwicklungszertifikat – mkcert und openssl sind die Alternativen für Browser-Komfort und Ops-Welt ✅ Fünf Properties machen aus deiner Spring-Boot-App einen HTTPS-Server mit HTTP/2 ✅ SSL Bundles mit Hot-Reload sind der Produktions-Standard ab Spring Boot 3.1
Egal ob du heute zum ersten Mal einen Keystore angefasst hast oder deine TLS-Konfiguration modernisiert hast – du hast etwas Neues gelernt. Das zählt!
Und denk dran: Security muss nicht perfekt sein, um wertvoll zu sein. HTTPS mit selbstsigniertem Zertifikat lokal ist besser als „mach ich später“. Gut genug mit klarem Upgrade-Pfad schlägt perfekt-aber-nie-umgesetzt. Jedes Mal.
Fragen? Schreib uns:
- Code Sentinel: code-sentinel@java-developer.online
Nächster Teil: Wie du deine Spring-Boot-App hinter nginx betreibst – Reverse Proxy richtig konfiguriert 🚀
Keep learning, keep growing! 💚
Tags: #SpringBoot #HTTPS #Security #keytool #PKCS12 #HTTP2 #TLS #Java
© 2026 Java Fleet Systems Consulting | java-developer.online
