PKI und Zertifikate für interne Dienste

1. Warum interne PKI mehr ist als "ein selbstsigniertes Zertifikat"

Viele Labs starten mit einzelnen selbstsignierten Zertifikaten. Für ein oder zwei Testdienste ist das ausreichend, spätestens bei Reverse Proxy, Monitoring, VPN, Proxmox, Gitea oder internen APIs wird es jedoch unübersichtlich. Dann braucht man keine "große Enterprise-PKI", aber eine klare interne Vertrauenskette.

Eine kleine PKI löst drei praktische Probleme:

  • Browser- und API-Warnungen verschwinden, weil Zertifikate sauber validierbar sind.
  • Dienste bekommen reproduzierbare Hostnamen und nachvollziehbare Laufzeiten.
  • Zertifikate lassen sich rotieren, ohne an jedem Client neue Ausnahmen zu klicken.

2. Vertrauensmodell: Root CA, Intermediate CA und Clients

Das saubere Minimalmodell besteht aus:

  • Root CA: höchstes Vertrauensobjekt, möglichst offline oder zumindest sehr gut geschützt.
  • Intermediate CA: signiert im Alltag Server- oder Client-Zertifikate.
  • End-Entity-Zertifikate: Zertifikate für Webserver, APIs, Clients oder Dienste.

Warum diese Trennung sinnvoll ist:

  • Wenn die Intermediate kompromittiert wird, kann die Root sie widerrufen oder ersetzen.
  • Die Root muss nicht auf jedem Produktivsystem liegen.
  • Lebenszyklen bleiben klar: Root lang, Intermediate mittel, Endzertifikate kurz.

Für kleine Umgebungen ist eine Offline-Root plus eine online verfügbare Intermediate oft der beste Kompromiss zwischen Sicherheit und Alltagstauglichkeit.

3. Geeignete Werkzeuge für Homelab und kleine Umgebungen

Es gibt mehrere sinnvolle Wege zu einer internen PKI:

  • OpenSSL: maximal flexibel, aber im Alltag fehleranfälliger und manueller.
  • step-ca: sehr angenehm für kleine bis mittlere Self-Hosted-Setups mit ACME-Unterstützung.
  • HashiCorp Vault PKI: stark für dynamische und kurzlebige Zertifikate, aber komplexer.

Für Homelab, Reverse Proxy und klassische Server ist step-ca oft ein sehr guter Startpunkt, weil ACME, Token-basierte Provisionierung und Trust-Distribution sauber gelöst werden. Wer bereits Vault für Secrets einsetzt, kann die PKI-Engine dort mitnutzen.

4. Zertifikate ausstellen und automatisieren

Die wichtigste Designfrage ist nicht "wie erzeuge ich ein Zertifikat?", sondern "wie erneuere ich es zuverlässig?". Zertifikate sollten möglichst automatisch und mit kurzen Laufzeiten ausgestellt werden.

Ein Beispiel mit step: 

step ca certificate grafana.internal.example \
  /etc/ssl/private/grafana.crt \
  /etc/ssl/private/grafana.key

Für Reverse Proxys oder Webserver ist ACME intern besonders praktisch. So lassen sich Zertifikate ähnlich komfortabel erneuern wie mit Let's Encrypt, nur eben für interne Domains und mit eigener CA.

Wichtige Regeln bei der Ausstellung:

  • SANs bewusst pflegen; der Common Name allein reicht nicht mehr.
  • Keine Wildcards als reflexartige Standardlösung, wenn eindeutige Hostzertifikate genügen.
  • Kurze Laufzeiten bevorzugen statt aufwändigem CRL-Management.
  • Schlüssel nie ungeschützt in Repositories oder Container-Images speichern.

5. Trust-Distribution und Lebenszyklus

Ein Zertifikat ist nur dann nützlich, wenn Clients der ausstellenden CA vertrauen. Deshalb gehört die Verteilung des Root- oder Intermediate-Zertifikats zum eigentlichen PKI-Projekt dazu.

  • Linux: CA nach /usr/local/share/ca-certificates legen und update-ca-certificates ausführen.
  • Windows: per GPO oder Zertifikatsspeicher verteilen.
  • Container: Basisimages gezielt mit interner CA ausstatten.
  • Mobile Clients: nur dort installieren, wo wirklich nötig.
sudo cp root-ca.crt /usr/local/share/ca-certificates/internal-root-ca.crt
sudo update-ca-certificates

Für den Lebenszyklus ist ein kleines Register hilfreich: Name, Verwendungszweck, ausstellende CA, Ablaufdatum und zuständiger Owner. Ohne diese Übersicht bemerkt man Zertifikatsabläufe oft erst, wenn Monitoring oder Apps bereits Fehler werfen.

6. mTLS und Service-Identitäten

Interne PKI ist nicht nur für Browser und Reverse Proxys nützlich. Mit mutual TLS kann man auch Dienste gegenseitig authentifizieren lassen. Das ist besonders interessant für:

  • interne APIs,
  • Admin-Zugänge,
  • Service-zu-Service-Kommunikation,
  • Monitoring-Endpunkte mit restriktivem Zugriff.

Wichtig ist dabei die Identität im Zertifikat: Ein Client-Zertifikat sollte nicht nur "irgendein Zertifikat" sein, sondern eine eindeutig nachvollziehbare Rolle oder Instanz repräsentieren, zum Beispiel prometheus.internal.example oder backup-client-01.

mTLS erhöht die Sicherheit deutlich, bringt aber auch Betriebsaufwand. Für ein kleines Lab reicht oft mTLS an wenigen sensiblen Stellen, statt es zwanghaft auf jeden einzelnen Dienst auszudehnen.

7. Betrieb, Widerruf und typische Fehler

Interne PKI scheitert selten an Kryptografie, sondern an Betrieb und Eigentümerschaft. Typische Probleme:

  • abgelaufene Zertifikate ohne Monitoring,
  • falsche SANs,
  • verteilte, aber nicht dokumentierte CA-Trust-Änderungen,
  • zu viele manuell ausgestellte Ausnahmen.

In kleinen Umgebungen sind kurze Laufzeiten und schnelle Neu-Ausstellung oft sinnvoller als komplexe Widerrufslogik über CRL oder OCSP. Widerruf bleibt wichtig, ist aber operativ nur dann hilfreich, wenn Clients diese Informationen auch tatsächlich prüfen. 

openssl x509 -in grafana.crt -noout -text
openssl verify -CAfile root-ca.crt grafana.crt
step certificate inspect grafana.crt

Monitoring sollte Abläufe früh erkennen, etwa 30 Tage vor Ablauf. Das ist deutlich billiger als nächtliche Fehlersuche wegen plötzlich ungültiger Zertifikate.

8. Zusammenfassung

Eine interne PKI muss nicht groß sein, aber sie sollte bewusst entworfen werden. Root und Intermediate trennen, Trust sauber verteilen, kurze Laufzeiten wählen und Zertifikate automatisiert erneuern: Das sind die Punkte, die im Alltag wirklich zählen.

Wer diese Grundlagen sauber aufsetzt, bekommt deutlich stabilere interne TLS-Workflows und vermeidet das ständige Hantieren mit Browser-Ausnahmen und manuell kopierten Zertifikatsdateien.