Vertrauenskette, Zertifikatstypen, interne PKI, Let's Encrypt und Formate mit OpenSSL.
Asymmetrische Kryptografie und warum ein Browser einem Zertifikat glaubt.
Zertifikate beruhen auf asymmetrischer Kryptografie: ein Schlüsselpaar aus öffentlichem und privatem Schlüssel. Was mit dem einen verschlüsselt/signiert wird, lässt sich nur mit dem anderen prüfen/entschlüsseln.
Ein Server-Zertifikat (Leaf) ist nur vertrauenswürdig, weil es Teil einer Chain of Trust ist:
Der Client prüft die Signaturen von unten nach oben bis zu einer Root, der er vertraut. Fehlt das Intermediate-Zertifikat auf dem Server, schlägt die Prüfung bei vielen Clients fehl („unable to get local issuer certificate").
Was validiert wird und wie viele Namen ein Zertifikat abdeckt.
Die Stufe (DV/OV/EV) sagt aus, wie streng die CA die Identität prüft, die kryptografische Sicherheit der Verschlüsselung ist bei allen gleich. Umfang (Single/Wildcard/SAN) sagt, wie viele Namen abgedeckt sind.
| Typ | Prüfung / Abdeckung | Einsatz |
|---|---|---|
| DV Domain Validated | Nur Kontrolle über die Domain (DNS/HTTP-Challenge). In Minuten, automatisiert. | Standard-Websites, APIs, interne Dienste. Let's Encrypt ist DV. |
| OV Organization Validated | CA prüft zusätzlich die Existenz der Organisation. | Firmen-Websites, wo der Betreiber sichtbar sein soll. |
| EV Extended Validation | Umfangreiche rechtliche Prüfung der Organisation. | Banken, Zahlungsdienste. Heute optisch kaum noch hervorgehoben. |
| Wildcard | Deckt alle Subdomains einer Ebene ab: *.example.com. |
Viele Subdomains unter einer Domain. Nicht mehrstufig (*.a.example.com ≠ *.example.com). |
| SAN / Multi-Domain | Mehrere feste Namen in einem Zertifikat (Subject Alternative Names). | Ein Zertifikat für example.com, www.example.com, mail.example.com … |
Moderne Clients ignorieren das alte Common Name-Feld und werten ausschließlich die Subject Alternative Names (SAN) aus. Jeder Name, unter dem ein Dienst erreichbar sein soll, muss als SAN im Zertifikat stehen, auch wenn er dem CN entspricht.
Selbst eine CA betreiben, oder Zertifikate von einer öffentlichen Stelle holen?
Öffentliche CAs (Let's Encrypt, DigiCert, Sectigo …) sind in allen gängigen Browsern/OS von Haus aus als vertrauenswürdig hinterlegt. Für alles, was aus dem Internet erreichbar ist (Websites, Mailserver, VPN-Gateways mit öffentlichem Namen), sind sie gesetzt, der Nutzer muss nichts installieren.
Eine interne PKI, in Windows-Umgebungen die AD Certificate Services (AD CS), stellt eigene Zertifikate aus. Damit sie vertraut werden, wird die Root-CA einmalig per GPO in den Zertifikatspeicher aller Domänenrechner verteilt. Sinnvoll für:
server.firma.local), für die keine öffentliche CA ausstellen darf.Wichtig: Öffentliche CAs stellen seit Jahren keine Zertifikate mehr für interne TLDs wie .local oder reine Hostnamen aus. Wer solche Namen absichern will, braucht eine interne PKI, oder benennt Dienste auf echte, öffentlich auflösbare (Sub-)Domains um und nutzt Split-DNS.
Kostenlose DV-Zertifikate, die sich selbst erneuern.
Let's Encrypt ist eine kostenlose, automatisierte öffentliche CA. Die Ausstellung läuft über das ACME-Protokoll (Automatic Certificate Management Environment): Ein Client (z. B. certbot, acme.sh, oder eingebaut in Reverse-Proxys wie Caddy, Traefik, Nginx Proxy Manager) beweist der CA die Kontrolle über die Domain und bekommt automatisch das Zertifikat.
/.well-known/acme-challenge/ ab, braucht Port 80 erreichbar.Let's-Encrypt-Zertifikate sind nur 90 Tage gültig. Das ist Absicht: Die Erneuerung muss automatisiert laufen (typisch ein Cron-/Timer-Job, der alle 60 Tage erneuert). Manuell ist das nicht handhabbar, und genau darin liegt der Sicherheitsgewinn: kurzlebige, automatisch rotierte Zertifikate.
Ausstellung inkl. Nginx-Konfiguration; die Erneuerung übernimmt der System-Timer.
PEM, DER, PFX, und wie man mit OpenSSL dazwischen wechselt.
| Format | Kodierung / Inhalt | Typisch für |
|---|---|---|
| PEM (.pem/.crt/.cer/.key) | Base64, Textblöcke -----BEGIN …-----. Kann Zertifikat, Kette und Key enthalten. |
Linux, Apache, Nginx, OpenSSL |
| DER (.der/.cer) | Binär (nicht lesbar). Ein Objekt pro Datei. | Java, manche Appliances |
| PFX / PKCS#12 (.pfx/.p12) | Binärer, passwortgeschützter Container: Zertifikat + Kette + privater Schlüssel zusammen. | Windows (IIS), Import/Export von Keys |
| CRT / KEY | Nur Namenskonvention: .crt = Zertifikat, .key = privater Schlüssel (meist PEM). |
Getrennte Ablage bei Nginx/Apache |
Der Certificate Signing Request (CSR) enthält den öffentlichen Schlüssel und die gewünschten Namen; der private Schlüssel bleibt bei dir.
Häufig, wenn ein Zertifikat aus Windows (PFX) auf einen Linux-Webserver (PEM) soll, oder umgekehrt.
Inhalt anzeigen, Gültigkeit/SAN prüfen und sicherstellen, dass Key und Zertifikat zusammenpassen.
Damit Zertifikate nicht zur Störungsquelle werden.