Ein Entwickler-Leitfaden zu SSL-Zertifikaten

Dec 4, 2025 · 4 min read

Ein Entwickler-Leitfaden zu SSL-Zertifikaten

Sie haben Ihre API bereitgestellt, lokal funktioniert alles einwandfrei, und dann bricht die Produktionsumgebung mit einem Zertifikatsfehler zusammen. Vielleicht ist es über Nacht abgelaufen. Vielleicht ist die Zertifikatskette unvollständig. Vielleicht haben Sie eine Konfiguration geerbt, bei der jemand Zertifikate einmal im Jahr manuell erneuert hat und keine Dokumentation hinterlassen hat.

Zertifikatsfehler verursachen echte Ausfälle. Microsoft, Slack und unzählige andere haben dies öffentlich erfahren müssen. Für Entwickler, die HTTPS-fähige Websites oder APIs bereitstellen, ist das Verständnis von SSL-Zertifikaten keine Option – es ist grundlegend.

Dieser Leitfaden behandelt, was Zertifikate tatsächlich sind, wie moderne Bereitstellungen sie erhalten und erneuern, und welche Praktiken Ihre Systeme am Laufen halten, während die Branche auf kürzere Zertifikatslaufzeiten zusteuert.

Wichtigste Erkenntnisse

TLS-Zertifikate binden öffentliche Schlüssel an Domain-Identitäten und benötigen eine vollständige Vertrauenskette, um ordnungsgemäß zu funktionieren
DV-, OV- und EV-Zertifikate bieten identische Verschlüsselung – die Unterschiede liegen im Validierungsprozess, nicht in der Sicherheitsstärke
Automatisierte Erneuerung über ACME ist mittlerweile obligatorisch, da die Zertifikatslaufzeiten bis 2029 auf 47 Tage schrumpfen
Vermeiden Sie Certificate Pinning, manuelle Erneuerungsprozesse und fest codierte CA-Annahmen, um Betriebsausfälle zu verhindern

Was ein Zertifikat tatsächlich ist

Ein TLS-Zertifikat bindet einen öffentlichen Schlüssel an eine Identität (normalerweise einen Domainnamen). Wenn ein Browser eine Verbindung zu Ihrem Server herstellt, prüft er, ob das Zertifikat gültig, nicht abgelaufen und von einer vertrauenswürdigen Certificate Authority (CA) signiert ist.

Die Vertrauenskette funktioniert folgendermaßen: Ihr Zertifikat wird von einer Intermediate-CA signiert, die wiederum von einer Root-CA signiert ist, der Browser und Betriebssysteme bereits vertrauen. Wenn ein Glied bricht – fehlendes Intermediate-Zertifikat, abgelaufene Root-CA, falsche Domain – schlägt die Verbindung fehl.

Zertifikate enthalten ein Subject Alternative Name (SAN)-Feld, das auflistet, für welche Domains oder IP-Adressen sie gültig sind. Das alte Common Name (CN)-Feld ist für Validierungszwecke veraltet. Moderne Clients erfordern SAN.

DV, OV und EV: Was wirklich zählt

Domain Validation (DV)-Zertifikate beweisen, dass Sie eine Domain kontrollieren. Die Validierung ist automatisiert und dauert Sekunden.

Organization Validation (OV) und Extended Validation (EV) beinhalten manuelle Überprüfungen Ihrer juristischen Person. Sie kosten mehr und dauern länger.

Was praktisch wichtig ist: Die Verschlüsselung ist identisch. EV-Zertifikate zeigten einst eine grüne Adressleiste, aber Browser haben diese UI-Unterscheidung entfernt. Für die meisten Entwickler sind DV-Zertifikate von Let’s Encrypt ausreichend und kostenlos.

Bauen Sie keine Annahmen auf EV-visuellen Indikatoren auf – sie sind verschwunden.

Der TLS-Zertifikatslebenszyklus und Automatisierung

Öffentliche TLS-Zertifikate sind kurzlebig und werden immer kürzer. Let’s Encrypt stellt 90-Tage-Zertifikate aus. Das CA/Browser Forum hat bereits eine stufenweise Reduzierung der maximalen Zertifikatslaufzeiten genehmigt, beginnend mit einer 200-Tage-Obergrenze im Jahr 2026 und einer Bewegung in Richtung 47 Tage bis 2029.

Dies macht die automatisierte Zertifikatsausstellung und -erneuerung obligatorisch, nicht optional. Manuelle Erneuerungsprozesse werden im großen Maßstab scheitern.

Der Standardansatz verwendet das ACME-Protokoll, das den gesamten Lebenszyklus automatisiert:

Ihr ACME-Client fordert ein Zertifikat an
Die CA fordert Sie auf, die Domain-Kontrolle zu beweisen (über HTTP oder DNS)
Sie antworten automatisch auf die Challenge
Die CA stellt ein signiertes Zertifikat aus
Ihr Client installiert es und plant die Erneuerung

Certbot ist der gängigste ACME-Client, aber es gibt Alternativen für jeden Stack: acme.sh für Shell-Umgebungen, Caddy mit integriertem ACME und Bibliotheken für Node.js, Go und Python.

ACME und Let’s Encrypt Best Practices

Integrieren Sie die Erneuerung in Ihre Deployment-Pipeline, nicht daneben. Zertifikate sollten automatisch ohne menschliches Eingreifen erneuert werden.

Wichtige Praktiken:

Frühzeitig erneuern: Lösen Sie die Erneuerung aus, wenn noch 30+ Tage verbleiben, nicht erst bei Ablauf
Ablauf überwachen: Verwenden Sie Tools wie cert-manager für Kubernetes oder einfache Cron-basierte Benachrichtigungen
Erneuerung testen: Führen Sie certbot renew --dry-run oder Äquivalente in CI aus
CA-Lock-in vermeiden: Codieren Sie keine Annahmen darüber fest, welche CA Sie verwenden

Speichern Sie private Schlüssel sicher. Committen Sie sie niemals in Repositories. Verwenden Sie ein für Ihre Plattform geeignetes Secrets Management.

Kurzlebige und IP-TLS-Zertifikate

Kurzlebige Zertifikate (Stunden bis Tage) reduzieren das Zeitfenster der Gefährdung, wenn ein Schlüssel kompromittiert wird. Einige Organisationen stellen Zertifikate aus, die 24 Stunden oder weniger gültig sind.

IP-TLS-Zertifikate – Zertifikate für IP-Adressen statt Domainnamen – sind wichtig für Entwicklungs- und DevOps-Szenarien, in denen DNS nicht verfügbar ist. Let’s Encrypt unterstützt jetzt kurzlebige IP-Zertifikate über ACME und richtet sie an der breiteren Bewegung hin zu automatisierter, kurzzeitiger Ausstellung aus.

Für die lokale Entwicklung erstellen Tools wie mkcert lokal vertrauenswürdige Zertifikate, ohne öffentliche CAs einzubeziehen.

Vorbereitung auf Post-Quantum-fähiges TLS

Quantencomputer werden schließlich aktuelle kryptografische Algorithmen brechen. Große Anbieter setzen bereits hybrides Post-Quantum-TLS in der Produktion ein, obwohl dies nichts ist, was App-Entwickler manuell konfigurieren müssen.

Als Anwendungsentwickler müssen Sie dies nicht selbst implementieren. Halten Sie Ihre TLS-Bibliotheken aktuell, verwenden Sie aktuelle Konfigurationen und vermeiden Sie veraltete Algorithmen wie SHA-1 oder RSA-Schlüssel unter 2048 Bit.

Der Übergang wird auf Bibliotheks- und Infrastrukturebene stattfinden. Ihre Aufgabe ist es, ihn nicht mit veralteten Abhängigkeiten oder fest codierten Annahmen zu blockieren.

Annahmen, die schlecht altern

Vermeiden Sie diese Muster:

Mehrjährige Zertifikate erwarten: Die maximale Gültigkeit schrumpft
CA-Identität fest codieren: CAs können das Vertrauen verlieren und Roots rotieren
Manuelle Erneuerungsprozesse: Sie skalieren nicht und schlagen stillschweigend fehl
Certificate Pinning: Erzeugt operative Albträume, wenn Zertifikate sich ändern
Zertifikatsinventar ignorieren: Sie können nicht erneuern, was Sie nicht verfolgen

Fazit

Modernes TLS-Zertifikatsmanagement erfordert Automatisierung. Die Branche bewegt sich in Richtung kürzerer Laufzeiten, was bedeutet, dass ACME-Clients, Erneuerungs-Pipelines und Monitoring zum Standard gehören.

Verwenden Sie Let’s Encrypt oder ähnliche automatisierte CAs. Integrieren Sie die Erneuerung in Ihren Deployment-Prozess. Verfolgen Sie Ihre Zertifikate. Halten Sie Ihre Bibliotheken aktuell. Diese Praktiken werden Ihre HTTPS-Bereitstellungen zuverlässig am Laufen halten, während sich die Standards weiterentwickeln.

FAQs

Wenn ein Zertifikat abläuft, verweigern Browser und Clients die Herstellung sicherer Verbindungen zu Ihrem Server. Benutzer sehen Warnmeldungen, API-Aufrufe schlagen fehl und automatisierte Systeme brechen zusammen. Die meisten modernen Browser blockieren den Zugriff vollständig, anstatt Benutzern das Fortfahren zu ermöglichen. Deshalb ist die automatisierte Erneuerung mit frühzeitigen Auslösern so wichtig.

Ja, durch Subject Alternative Names (SANs). Ein einzelnes Zertifikat kann mehrere Domains oder Subdomains in seinem SAN-Feld auflisten. Wildcard-Zertifikate decken alle Subdomains einer einzelnen Ebene ab, wie *.example.com. Wildcards erfordern jedoch DNS-basierte Validierung und decken die Root-Domain nicht automatisch ab.

Kurze Gültigkeitszeiträume verbessern die Sicherheit, indem sie die Expositionszeit begrenzen, falls ein privater Schlüssel kompromittiert wird. Sie erzwingen auch Automatisierung, was menschliche Fehler reduziert. Das CA/Browser Forum drängt die Gültigkeit noch kürzer, auf 47 Tage bis 2029, was manuelle Erneuerungsprozesse zunehmend unpraktikabel macht.

Im Allgemeinen nein. Certificate Pinning bindet Ihre Anwendung an bestimmte Zertifikate oder öffentliche Schlüssel, was ernsthafte operative Probleme verursacht, wenn Zertifikate rotieren. Wenn Sie Pinning verwenden und dann unerwartet Zertifikate ändern müssen, bricht Ihre Anwendung zusammen. Moderne Alternativen wie Certificate Transparency Logs bieten Sicherheitsvorteile ohne das operative Risiko.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.