# Private CA: Das eigene Vertrauenszentrum im LAN

TL;DR / Management Summary Für interne Dienste (Proxmox-GUI, Firmen-Wiki, interne APIs) sind öffentliche Zertifikate oft zu teuer oder technisch nicht möglich. Die Lösung ist eine Private CA. Wir erstellen unser eigenes Root-Zertifikat, dem alle Firmen-Laptops vertrauen. Ein Senior Admin nutzt diese Infrastruktur, um unbegrenzt viele, vertrauenswürdige Zertifikate für das interne Netzwerk auszustellen, ohne auf externe Anbieter angewiesen zu sein.

# 1. Einführung & Architektur

Die Vertrauenskette.

Eine Private CA besteht aus einem Root-Zertifikat (sehr sicher, meist offline gelagert) und einem oder mehreren Intermediate Zertifikaten, mit denen die eigentlichen Server-Zertifikate signiert werden.

# Die CA-Hierarchie (Mermaid)

graph TD
    A[Root CA: Internal Root] -->|Signs| B[Intermediate CA: Issuing]
    B -->|Signs| C[Server Cert: wiki.intern]
    B -->|Signs| D[Server Cert: pve.intern]
    E[Client: Laptop / Server] -->|Trusts| A
    E -->|Validates| C
    E -->|Validates| D
    subgraph "Storage"
        A --- F[Offline USB / Safe]
        B --- G[Online Security Server]
    end

# 2. Praxis: Die eigene CA erstellen

Vom Root zum Server.

# Schritt 1: Root CA erstellen

# 1. Private Key (Extrem sicher aufbewahren!)
openssl genrsa -aes256 -out rootCA.key 4096

# 2. Selbstsigniertes Root-Zertifikat
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem

# Schritt 2: Server-Zertifikat signieren

Angenommen, Sie haben einen CSR (server.csr, siehe Artikel 319) von Ihrem Wiki-Server erhalten:

openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial \
    -out server.crt -days 825 -sha256 -extfile server.ext

(Hinweis: server.ext sollte SAN-Einträge für IPs und Hostnames enthalten).

# 3. Vertrauen herstellen: Root-Zertifikat verteilen

Damit der Browser grün wird.

Der schwierigste Teil ist, dass alle Clients der neuen CA vertrauen.

# Unter Ubuntu / Debian

sudo cp rootCA.pem /usr/local/share/ca-certificates/company-root.crt
sudo update-ca-certificates

# Unter RHEL / Fedora / Arch

sudo cp rootCA.pem /etc/pki/ca-trust/source/anchors/company-root.pem
sudo update-ca-trust extract

# 4. Day-2 Operations: Zertifikats-Lifecycle

Wartung der PKI.

# Sperrlisten (CRL)

Was passiert, wenn ein interner Server gehackt wurde? Sie müssen das Zertifikat für ungültig erklären.

• CRL (Certificate Revocation List): Eine Datei, die alle gesperrten Zertifikats-IDs enthält.
• OCSP: Ein Echtzeit-Protokoll zur Prüfung der Gültigkeit.

# 5. Troubleshooting & “War Stories”

Wenn die Kette bricht.

# Story 1: “Der SAN-Fehler”

Symptom: Das Zertifikat ist installiert und die CA ist vertrauenswürdig, aber Chrome meldet trotzdem “Zertifikat ungültig (Subject Alternative Name Missing)”. Ursache: Moderne Browser ignorieren das Feld Common Name (CN). Sie verlangen zwingend Einträge im Feld Subject Alternative Name (SAN). Lösung: Erstellen Sie eine Extension-Datei für OpenSSL beim Signieren: subjectAltName = DNS:wiki.company.local, IP:10.0.0.10.

# Story 2: “Das abgelaufene Root-Zertifikat”

Symptom: Nach 5 Jahren funktionieren plötzlich hunderte interne Dienste nicht mehr. Ursache: Das Root-Zertifikat der Firma ist abgelaufen. Da alle anderen Zertifikate davon abhängen, ist die gesamte Kette ungültig. Lösung: Planen Sie die Erneuerung der Root-CA 12 Monate vor Ablauf ein. Die Verteilung des neuen Zertifikats an tausende Clients ist ein massiver logistischer Aufwand.

# 6. Fazit & Empfehlung

• Offline-Root: Nutzen Sie niemals den Root-Key auf einem vernetzten Server. Generieren Sie ihn offline und nutzen Sie eine Intermediate CA für das tägliche Signieren.
• Automation: Für größere Umgebungen nutzen Sie HashiCorp Vault (PKI Engine) oder Step-ca. Diese Tools automatisieren den Signierungsvorgang via API.
• Wahl: Nutzen Sie Let’s Encrypt (Artikel 322) für alles, was über das Internet erreichbar ist. Nutzen Sie die Private CA nur für rein interne “Islands”.

# Anhang: Cheatsheet